Allow parsing of custom window features, such as 'moo=foo'.

Allow parsing of custom window features, such as 'moo=foo'.

This patch is part of a bigger patch for #110510, which allows custom window features on popup windows to be propagated to other handlers, such as ContentBrowserClient::CanCreateWindow(). This is particularly helpful in frameworks such as CEF, which allows third-parties to integrate with Chromium and provide custom handling for specific window features.

A separate code review for the Chromium part of this bug is available here: https://codereview.chromium.org/15994016

BUG=110510

[commit-bot: I haz the power, 2013-06-04 16:02:08]

No comments yet.

[dreijer, 2013-06-04 18:29:26]

This patch is part of a bigger patch for #110510, which allows custom window
features on popup windows to be propagated to other handlers, such as
ContentBrowserClient::CanCreateWindow(). This is particularly helpful in
frameworks such as CEF, which allows third-parties to integrate with Chromium
and provide custom handling for specific window features.

A separate code review for the Chromium part of this bug is available here:
https://codereview.chromium.org/15994016

[dreijer, 2013-06-04 18:32:06]

On 2013/06/04 18:29:26, dreijer wrote:
> This patch is part of a bigger patch for #110510, which allows custom window
> features on popup windows to be propagated to other handlers, such as
> ContentBrowserClient::CanCreateWindow(). This is particularly helpful in
> frameworks such as CEF, which allows third-parties to integrate with Chromium
> and provide custom handling for specific window features.
> 
> A separate code review for the Chromium part of this bug is available here:
> https://codereview.chromium.org/15994016

Note that I don't know how to resolve the lint error "If an else has a brace on
one side, it should have it on both". I'm not allowed to use curly braces on
single line if-statements, so I can't put a curly brace on the left side of the
'else'.

[eseidel, 2013-06-28 20:25:43]

I'm lacking sufficient context here.

[abarth-chromium, 2013-06-29 00:59:12]

not lgtm

As far as I can tell, this change is motivated by wanting to process
non-standard window features.  I don't think we want to support proprietary
extensions to window features.  Instead, we prefer to support standards-based
features.

[dreijer, 2013-07-15 14:58:08]

On 2013/06/29 00:59:12, abarth wrote:
> not lgtm
> 
> As far as I can tell, this change is motivated by wanting to process
> non-standard window features.  I don't think we want to support proprietary
> extensions to window features.  Instead, we prefer to support standards-based
> features.

Sorry for the slow reply. Vacation time and all that jazz.

I'm a user of CEF (http://code.google.com/p/chromiumembedded/), which uses the
Chromium Content API to allow third-party applications access to Chromium. In my
specific case, we're using Chromium as our plugin framework (HTML and JS-based)
and it's imperative that we can pass custom features from a plugin page through
to the native client.

By preventing non-standard window features, you're arbitrarily limiting users
like me from getting the full potential out of Chromium. What's the rationale
behind preventing such features to trickle through Webkit to Chromium?

[abarth-chromium, 2013-07-15 21:04:19]

> What's the rationale
> behind preventing such features to trickle through Webkit to Chromium?

I'm sorry that your use case isn't contained within the goals of this project. 
You might consider creating a branch on GitHub or elsewhere and making your
changes on that branch.  Unfortunately, this feature does not belong in trunk.

[dreijer, 2013-07-15 21:10:58]

On 2013/07/15 21:04:19, abarth wrote:
> > What's the rationale
> > behind preventing such features to trickle through Webkit to Chromium?
> 
> I'm sorry that your use case isn't contained within the goals of this project.

> You might consider creating a branch on GitHub or elsewhere and making your
> changes on that branch.  Unfortunately, this feature does not belong in trunk.

I'm sorry too, of course. It'd still be nice with an explanation of why this
specific use case is undesired in Chromium. I'm curious what downsides there are
to allow something upstream to parse custom features. Chromium itself can still
only care about the "official" features and throw everything else away, i.e.
you're just moving this decision from inside of Webkit to Chromium, which would
probably be able to make a more educated guess as to what's allowed anyway.

[abarth-chromium, 2013-07-15 21:16:05]

On 2013/07/15 21:10:58, dreijer wrote:
> I'm sorry too, of course. It'd still be nice with an explanation of why this
> specific use case is undesired in Chromium.

The purpose of the Chromium project is to build a great browser.  It's great
that other folks find the code useful for other purposes, but we're not
interested in adding complexity to the code to support those use cases.

> I'm curious what downsides there are
> to allow something upstream to parse custom features.

These custom features are not web standards.  Blink is focused on support
standard web technologies.  Having extra complexity in the code base to support
non-standard, non-browser use cases is a cost, and we've chosen not to take on
that cost.

> Chromium itself can still
> only care about the "official" features and throw everything else away, i.e.
> you're just moving this decision from inside of Webkit to Chromium, which
would
> probably be able to make a more educated guess as to what's allowed anyway.

Unfortunately, the code would still exist in the code base, which means other
developers need to maintain the code.  You could argue that the maintenance cost
is small, but it's non-zero.  We don't wish to pay that maintenance cost. 
Instead, you're welcome to use the code for your own purposes (it's open source
after all), and you're welcome to maintain your own modifications in your own
branch.  We're just not going to accept them into trunk.