?
On Thu, Aug 9, 2012 at 11:33 AM, Jesse <[email protected]> wrote: > Can we get more than an hour? > > On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux <[email protected]> wrote: > >> 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 >> >> >>>>> >> >> >> > > > > -- > @purplecabbage > risingj.com
