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 <shaz...@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. >
