I'd rather we continue to encourage single page apps as the best practice for building apps w/ html, css, and js. The many views architecture seems like it would create a strong coupling to the native side (for transitioning esp so).
I view the cleaver-ing as creating a transition path for native apps to cordova apps and/or allowing the facebook/linkedin/twitter webview with native chrome use case (which I do not love but understand the desire for it in some cases). On Wed, Aug 8, 2012 at 11:55 AM, Jesse MacFadyen <[email protected]> wrote: > 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 >>>>
