incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 18:24:55 GMT
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
<michael@michaelbrooks.ca> wrote:
> Nice Dave, those conditions make sense to me.
>
> On Thu, Aug 9, 2012 at 10:54 AM, Dave Johnson <dave.c.johnson@gmail.com>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 <b@brian.io> 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
>> > <purplecabbage@gmail.com> 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 <b@brian.io> 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 <purplecabbage@gmail.com>
>> 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 <purplecabbage@gmail.com>
>> 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 <brion@pobox.com>
>> 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
>> >>>>>
>>

Mime
View raw message