> - 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
