In the future we may want to allow multi-view apps, as this was part of the reasoning for cleaving the view... does this change anything?
Cheers, Jesse Sent from my iPhone On 2012-08-08, at 11:28 AM, Brian LeRoux <[email protected]> wrote: > 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 >>>
