I'll add a task in JIRA - with sub-tasks for the diff platforms (will start with Android and iOS)
On Thu, Aug 9, 2012 at 12:44 PM, Brian LeRoux <[email protected]> wrote: > started a wiki page to document; no one has to jump into doing > anything until comfortable (obviously?) > > http://wiki.apache.org/cordova/InAppBrowser > > > > On Thu, Aug 9, 2012 at 12:16 PM, Jesse <[email protected]> wrote: >> I am good with all of that. >> >> Can we fully document this before we jump to doing it? >> >> >> On Thu, Aug 9, 2012 at 12:11 PM, Dave Johnson >> <[email protected]>wrote: >> >>> > - 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? >>> >>> yes that changes the options. If not present then all things that go >>> to InAppBrowser just go to native browser. >>> >>> > - is there still an InAppBrowser api where I can actively attempt to load >>> > any url in the InAppBrowser? ( whether it is whitelisted or not ) >>> >>> sure >>> >>> >>> On Thu, Aug 9, 2012 at 11:58 AM, Jesse <[email protected]> wrote: >>> > 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 >>> >> >> >> >> -- >> @purplecabbage >> risingj.com
