Jesse: I like it. My personal take is the primary use case we want to fulfill is the ability to see content in a browser. Unfortunately iOS this means leaving the app context which isn't the best experience thus the need for a ChildBrowser.
For this use case I do not see the need for access to the native bridge. Maybe I'm missing something but would it not reduce the complexity if the childbrowser had no bridge capability? is there a drawback if this is the case? (Obv the system browser has no native bridge.) Also, we really should come up with a better name than 'Child Browser'. =/ On Tue, Aug 7, 2012 at 4:30 PM, Jesse <[email protected]> wrote: > Brion: > Yes, this should be considered part of the API, the 'how' is yet to be > defined, but apps need the ability to specifically target both the default > system browser AND the ChildBrowser. > > === > > Re: My Proposal, ( I have officially flipped ... ) > > After writing/sending my proposal, I thought back to the origins of the > ChildBrowser plugin. Back when Shaz and I wrote it some 2+ years ago, the > goal was to allow non-secure content to be loaded into the application > without offering any chance of the app/dom being hijacked. At the time, > there was no whitelist, and all was fine. > > Now that we have a whitelist, I think we need to re-evaluate it's purpose. > IMHO the ChildBrowser should NOT be restricted to domains in the > whitelist. If you imagine attempting to develop a twitter clone, it would > be impossible to display links in tweets unless you either, jumped out to > the system browser, or had an allow * in the whitelist. IMO this is a > perfectly valid use case for building a phonegap app. > > Displaying content from ANY domain should be a perfectly acceptable > practice. > Running JS code inside the ChildBrowser from ANY domain should be > acceptable as well. ( XHR cross-domain requests should continue to be > governed by the security already present in the browser control itself ) > Mixing code/content from the internet domain with the app domain SHOULD be > governed by the whitelist. > > The ChildBrowser already shields the app from unsafe internet code, in that > it does NOT allow any of the APIs that phonegap does. This is in harmony > with the initial intent of the plugin, to safely display some content ... > and not lose the app context. > > My adjusted proposal follows : > > 1. The security/whitelist checking should be adjusted to only apply to > access attempts by the CDVViewController, and not the entire application. ( > not easy, I know Shaz, I can help ) > 2. If ChildBrowser is present, it should include code to intercept > target._blank and polyfil window.open to its own API. (JS POC needed) > 3. ChildBrowser should get an additional API to specifically target > the system default browser. ( API details TBD ) > > Cheers, > Jesse > > > > > On Mon, Aug 6, 2012 at 4:55 PM, Brion Vibber <[email protected]> wrote: > >> On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen <[email protected] >> >wrote: >> >> > [PROPOSAL] >> > >> > 1. If a URL is not in the whitelist, it will be passed to the default >> > system browser regardless of any other rule. ( this will be handled on >> > the native side, by the framework and the JS side may not even know it >> > has happened. ) >> > >> >> If the URL *is* in the whitelist, can we send it to the default system >> browser too when calling window.open? >> >> For lots of our usage at Wikimedia, we need to whitelist Wikipedia sites in >> order to do API calls via XHR (at least on iOS), but also want to be able >> to open specific pages in the system browser. >> >> 2. If ChildBrowser is present, it should include code to intercept >> > target._blank and polyfil window.open to its own API. >> > 3. ChildBrowser should get an additional API to specifically target >> > the system default browser. >> > >> >> -- brion vibber (brion @ pobox.com / brion @ wikimedia.org) >> > > > > -- > @purplecabbage > risingj.com
