incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [DISCUSS] window.open target blank
Date Wed, 08 Aug 2012 00:04:07 GMT
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message