Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D5B0E9520 for ; Thu, 9 Aug 2012 18:49:59 +0000 (UTC) Received: (qmail 68446 invoked by uid 500); 9 Aug 2012 18:49:59 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 68422 invoked by uid 500); 9 Aug 2012 18:49:59 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 68410 invoked by uid 99); 9 Aug 2012 18:49:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2012 18:49:59 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com designates 74.125.83.47 as permitted sender) Received: from [74.125.83.47] (HELO mail-ee0-f47.google.com) (74.125.83.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2012 18:49:55 +0000 Received: by eekb57 with SMTP id b57so204995eek.6 for ; Thu, 09 Aug 2012 11:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=1hZOLQRn9M/4dnyIjw4LhOJaMh/JNjrjNIhwVsJt9Nc=; b=eWvgHmno417UQE0MWJgUxMC1+PDrA8eJ78i7PYoVpjftZ0d8G7s26sIUTm8ElMw+xP QOxJit8s+P0RsIlkB4NF5kEvJvApm83ztQQzjLZPVUwG6e8ccGBdgybVnIL69N/pHgul hmj4dp2IHz1bzMqxWgB9qGJ0oKTzi+EKYXZLW383nDg6gCwl/DYYyMfWS21eXAbteH13 sxtOZbMBOBiJ9YT5PGOJ3jT/DO9vt/kaMInWVGaKrgAoBY/E0g6tKNkNIIK+9SsCq/17 1XlvSKIOB483YRIHIHAF+eqz8kXLbY/JgOkWNxsvKlarRF/mn/2y8BaniIjDFr1MYxkL mzKw== MIME-Version: 1.0 Received: by 10.14.204.72 with SMTP id g48mr344191eeo.45.1344538173868; Thu, 09 Aug 2012 11:49:33 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.14.95.75 with HTTP; Thu, 9 Aug 2012 11:49:33 -0700 (PDT) In-Reply-To: References: <812916889958891609@unknownmsgid> <-2592107845858267218@unknownmsgid> <2921695748638837861@unknownmsgid> Date: Thu, 9 Aug 2012 11:49:33 -0700 X-Google-Sender-Auth: 6ZDX5a-Vkj_yrjorOS--0xmBIpc Message-ID: Subject: Re: [DISCUSS] window.open target blank From: Brian LeRoux To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org ? On Thu, Aug 9, 2012 at 11:33 AM, Jesse wrote: > Can we get more than an hour? > > On Thu, Aug 9, 2012 at 11:24 AM, Brian LeRoux 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 >> wrote: >> > Nice Dave, those conditions make sense to me. >> > >> > On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson > >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 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 >> >> > 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 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 < >> >> michael@michaelbrooks.ca> 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 >> >> 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 < >> >> michael@michaelbrooks.ca >> >> >>>>>> 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 >> >> 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 >> >> wrote: >> >> >>>>>>> >> >> >>>>>>>> On Mon, Aug 6, 2012 at 3:52 PM, Jesse MacFadyen < >> >> >>>>>> purplecabbage@gmail.com >> >> >>>>>>>>> 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