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
