Meant to reply to this. I think Mike is correct: _blank === system browser _self === child browser
Thoughts? * * * ChildBrowser === InAppBrowser <---not perfect but it gets rid of pedobear jokes On Tue, Aug 7, 2012 at 5:04 PM, Michael Brooks <[email protected]> wrote: >> >> 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 ) > > > Can we consider using the other anchor frame types? [1] To me, _blank > should still exit the app and open the default browser. Perhaps _self, > _parent, or _top can be intercepted to invoke the Child Browser (name > change pending)? > > - _blank: The user agent should load the designated document in a new, > unnamed window. > - _self: The user agent should load the document in the same frame as the > element that refers to this target. > - _parent: The user agent should load the document into the immediate > FRAMESET parent of the current frame. This value is equivalent to _self if > the current frame has no parent. > - _top: The user agent should load the document into the full, original > window (thus canceling all other frames). This value is equivalent to _self > if the current frame has no parent. > > [1] http://www.w3.org/TR/html401/types.html#type-frame-target > > Michael > > On Tue, Aug 7, 2012 at 4:58 PM, Jesse <[email protected]> wrote: > >> Brian, >> The ChildBrowser does NOT allow bridge access, it is a dumb view. >> The only way that it can communicate with the host app is via url changes ( >> a'la OAuth, NOT a'la PhoneGap gap:// commands. ) >> >> Michael, >> When you install a plugin, you should be aware of what the plugin does. >> This is a developer decision and not a framework responsibility IMHO. >> >> ChildBrowser name suggestions? Separate thread? >> >> >> >> On Tue, Aug 7, 2012 at 4:44 PM, Michael Brooks <[email protected] >> >wrote: >> >> > Great writeup Jesse. >> > >> > I agree with your reasoning and I like that Child Browser is not ruled by >> > the domain whitelist. >> > >> > One concern that I have is around other plugins. Consider the scenario of >> > an asset downloader that may download an archive (tar, gzip, etc), >> extract >> > it, and inject the assets into the application's DOM. Off the top of my >> > head, this sort of plugin should be restricted by the domain whitelist. >> > >> > Michael >> > >> > 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 >> > > >> > >> >> >> >> -- >> @purplecabbage >> risingj.com >>
