atom feed16 messages in org.apache.incubator.callback-devInAppBrowser api questions
FromSent OnAttachments
ShazronNov 9, 2012 9:43 am 
Nukul BhasinNov 9, 2012 12:24 pm 
Gord TannerNov 9, 2012 3:02 pm 
Nukul BhasinNov 9, 2012 3:16 pm 
ShazronNov 12, 2012 11:11 am 
Andrew GrieveNov 12, 2012 7:29 pm 
ShazronNov 15, 2012 1:58 am 
ShazronNov 15, 2012 3:58 pm 
ShazronNov 19, 2012 3:24 pm 
Simon MacDonaldNov 22, 2012 11:47 am 
Joe BowserNov 22, 2012 11:50 am 
Simon MacDonaldNov 22, 2012 1:30 pm 
Brian LeRouxNov 23, 2012 4:07 am 
Simon MacDonaldNov 23, 2012 4:38 am 
Brian LeRouxNov 23, 2012 4:48 am 
Simon MacDonaldNov 23, 2012 6:40 am 
Subject:InAppBrowser api questions
From:Shazron (
Date:Nov 9, 2012 9:43:48 am

WIki page: Some questions brought up by Jesse in JIRA (replicated below):

---------------------------------------------------- Jesse MacFadyen:

I have some open questions about the wiki defined 'spec'

1.'', '_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 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 works.