More than an hour to make a decision, we have been talking about this for months.
Questions: - is there a guarantee that the InAppBrowser is present, after all it is a plugin, even when it becomes a core plugin, it is still optional, isn't it? - is there still an InAppBrowser api where I can actively attempt to load any url in the InAppBrowser? ( whether it is whitelisted or not ) On Thu, Aug 9, 2012 at 11:49 AM, Brian LeRoux <[email protected]> wrote: > ? > > 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 > -- @purplecabbage risingj.com
