incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
Subject Re: [DISCUSS] window.open target blank
Date Thu, 09 Aug 2012 17:54:01 GMT
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