So---is this solid enough ground to open some issues / make this a part of 2.1?
(end of september) On Thu, Aug 9, 2012 at 10:59 AM, Michael Brooks <[email protected]> wrote: > Nice Dave, those conditions make sense to me. > > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson <[email protected]>wrote: > >> These are the window.open calls that we need to consider: >> >> 1) window.open('local-url.html', '_self'); // >> loads in CordovaView. _parent and _top same thing >> 2) window.open('local-url.html', '_blank'); // loads >> in InAppBrowser >> 3) window.open('http://whitelisted-url.com', '_self'); // loads in >> CordovaView >> 4) window.open('http://whitelisted-url.com', '_blank'); // loads in >> InAppBrowser >> 5) window.open('http://random-url.com', '_self'); // loads in >> InAppBrowser >> 6) window.open('http://random-url.com', '_blank'); // native browser >> >> window.location = 'foo' is equivalent to the '_self' options above. >> >> I'm operating under the assumption that local and whitelisted URLs >> should be opened with Cordova functionality by default (_self) and you >> have to be explicit if you want those trusted resources opened without >> Cordova functionality (_blank). >> >> >> On Wed, Aug 8, 2012 at 12:13 PM, Brian LeRoux <[email protected]> wrote: >> > 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 >> >>>>> >>
