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 Wed, 08 Aug 2012 18:28:31 GMT
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