Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Date: Thu, 29 Mar 2012 22:31:27 +0000 (UTC)
From: "Shazron Abdullah (Commented) (JIRA)" <jira@apache.org>
To: callback-dev@incubator.apache.org
Message-ID: 
 <935510218.35576.1333060287967.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <830433643.39208.1332284258806.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CB-362) [ios] target="_blank" links should open
 in browser (ignoring externalhosts)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CB-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241878#comment-13241878 ] 

Shazron Abdullah commented on CB-362:
-------------------------------------

*There are two types of anchor tag requests:*

 1. Has no target attribute
 2. Has a target attribute that should launch a new Mobile Safari window

For request type (1), the UIWebViewDelegate gets one NSURLRequest with navigationType UIWebViewNavigationTypeLinkClicked

For request type (2), the UIWebViewDelegate gets two NSURLRequests with the first being navigationType UIWebViewNavigationTypeLinkClicked, then the second with navigationType UIWebViewNavigationTypeOther

It is this two request process that prevents this issue from being an easy fix - since at the first request, the NSURLRequest can be rejected before we can process it for the second request (which differentiates it at being target="_blank"), where it can be accepted. 

How do I differentiate between the two types of anchor tags then, to fix this issue? You can't, not easily. This would require saving state (the request) when a UIWebViewNavigationTypeLinkClicked navigationType is encountered, waiting for a set interval then seeing if a request with navigationType UIWebViewNavigationTypeOther follows suit. If it doesn't, process the NSURLRequest normally. If it does, punt it to Mobile Safari. This can potentially be error prone.

I think what needs to happen is a change in the behaviour for handling anchor tags.

*Here's what I propose:*

If it's an anchor tag with NO target attribute - it can ONLY load file urls, no http urls. Thus only local files can be loaded in the UIWebView in this situation.

If it's an anchor tag WITH a target attribute - it can ONLY load external http urls, no file urls (besides Mobile Safari won't display any file urls). Thus only external files can be loaded in Mobile Safari in this situation.

With this new policy, all requests with navigationTypes of UIWebViewNavigationTypeLinkClicked, we need to wait for a subsequent request of navigationType UIWebViewNavigationTypeOther, always (and always return NO on this first request, if not the NSURLProtocol handler will kick in and reject it anyway).

If we don't receive the subsequent request (within a set interval) - we reject the request (return NO). If we receive the subsequent request, we process it for the whitelist normally.

This will not apply to child iframes because we detect that the request is from an iframe, and iframe requests can load external urls (if they pass the whitelist). This proposed new policy only applies to the main page loaded by the UIWebView.

Because of the complexity of this, this can't make it in 1.6.0


> [ios] target="_blank" links should open in browser (ignoring externalhosts)
> ---------------------------------------------------------------------------
>
>                 Key: CB-362
>                 URL: https://issues.apache.org/jira/browse/CB-362
>             Project: Apache Callback
>          Issue Type: Bug
>          Components: iOS
>    Affects Versions: 1.5.0
>            Reporter: Andrew Lunny
>            Assignee: Shazron Abdullah
>              Labels: externalhosts, whitelist
>             Fix For: 1.7.0
>
>
> A link such as this:
> {noformat}<a href="http://google.com" target="_blank">Google</a>{noformat}
> should open by default in the device's web browser, without being explicitly allowed in the plist (externalhosts).
> This is the current (and, imo, expected) behaviour on Android.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira