cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: InAppBrowser api questions
Date Mon, 12 Nov 2012 19:11:57 GMT
Bump. These questions below still need some discussion and consensus before
the InAppBrowser implementation can be complete.


On Fri, Nov 9, 2012 at 9:43 AM, Shazron <shazron@gmail.com> wrote:

> WIki page: http://wiki.apache.org/cordova/InAppBrowser
> Some questions brought up by Jesse in JIRA (replicated below):
> http://goo.gl/cZe84
>
> ----------------------------------------------------
> Jesse MacFadyen:
>
> I have some open questions about the wiki defined 'spec'
>
> 1. window.open('http://random-url.com', '_self'); // loads in InAppBrowser
>     so even though the random-url is not whitelisted, it is permitted to
> load within the application, inside the InAppBrowser. This is currently not
> trivial on iOS.
>
> 2. How can I open a whitelisted url in the native browser? ie. mobile
> safari
>     there is no clear path to targeting ALL 3 possibilities or a)the app
> page, b) the InAppBrowser, c) the system browser ( for a whitelisted URL )
>     it makes sense that you cannot open a file:// url in the system
> browser + you cannot open a non-whitelisted url in the app.
>
> ----------------------------------------------------
>
> My comments:
>
> 1. This as Jesse points out, is not trivial on iOS. The "easy way" would
> be to not allow this, but kick it out to the system browser (Mobile
> Safari), and have that as a general rule, any non-whitelisted URLs for the
> InAppBrowser are kicked out to the system browser. I don't know how hard it
> is for Android.
>
> If we were to do this, we would have to temporarily allow the url to
> bypass the whitelist which could be kludgy (since we can't know what other
> URLs that URL will load) -- essentially this issue
> http://issues.cordova.io/1695 would totally solve this correctly, but we
> don't have a solution yet for that issue.
>
> 2. This case has not been addressed. I would think _blank would be the
> case but this is specified as the InAppBrowser here. How about this case,
> we could use _parent for InAppBrowser, but _blank for system browser?
> However, this would not be consistent with how the other calls are
> specified (unless we change the others to be consistent).
>
> Another possible solution is to kick out to the system browser if an
> unknown value is used (some random value), that will use the system
> browser, which is consistent with how window.open works.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message