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 5265DD2D6 for ; Thu, 9 Aug 2012 17:54:48 +0000 (UTC) Received: (qmail 83054 invoked by uid 500); 9 Aug 2012 17:54:48 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 83019 invoked by uid 500); 9 Aug 2012 17:54:48 -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 83011 invoked by uid 99); 9 Aug 2012 17:54:48 -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 17:54:48 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dave.c.johnson@gmail.com designates 209.85.215.47 as permitted sender) Received: from [209.85.215.47] (HELO mail-lpp01m010-f47.google.com) (209.85.215.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2012 17:54:44 +0000 Received: by lagv3 with SMTP id v3so337689lag.6 for ; Thu, 09 Aug 2012 10:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Psk1zJtln4U1ZgUZ2ZQVUU31RyLmsf2kzQJpYD53mvs=; b=rHfGV4tZQ6s7ZmNS402buNsUkv7OoAFJL9jSwROivtnVEBr0ZdnD9qvXv4Ow4S4CO3 pZFDeEkktXsITCXUabL1pCD5V9czq7oT/ONsdi25lsNE6HRnF7VdbM2qHxz3Z7QZvmrK I0N4j4HoJxoihspl1xyYLN6yYYE/yL++lIU1OzDouQNGXbhgqTOnNB3XTiVChiQbynmQ zBB/YQfRluuq2/f8dEvx2p33UklFPVs6KSkXhXefPtnYEbEamzg/I2GyFXeyKbTduTfG bgj7by901J9maHK+KoZ7Z0CN9kv6ZwLfMpZ/ukUp1ez9I8vYiUowtphUSkCq2WTB9L9j l5Wg== Received: by 10.112.26.106 with SMTP id k10mr1171068lbg.100.1344534862326; Thu, 09 Aug 2012 10:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.71.74 with HTTP; Thu, 9 Aug 2012 10:54:01 -0700 (PDT) In-Reply-To: References: <812916889958891609@unknownmsgid> <-2592107845858267218@unknownmsgid> <2921695748638837861@unknownmsgid> From: Dave Johnson Date: Thu, 9 Aug 2012 10:54:01 -0700 Message-ID: Subject: Re: [DISCUSS] window.open target blank To: callback-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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 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 >>>>> 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 >>>>>