Show the 'unsupported flag' message for --{enable,disable}-blink-features.

Show the 'unsupported flag' message for --{enable,disable}-blink-features.

This causes Chrome to show a scary infobar when either of these flags is used,
in order to discourage their use in production. They are intended for Chromium
development only.

BUG=454504
Committed: https://crrev.com/446bce0a188c000a4b77e51fbc66af1fd22e0398
Cr-Commit-Position: refs/heads/master@{#317098}

[jbroman, 2015-02-13 22:52:52]

jbroman@chromium.org changed reviewers:
+ eseidel@chromium.org, pdr@chromium.org

[jbroman, 2015-02-13 22:52:53]

Possible mitigation to discourage enterprises from relying on this flag, without
making it less useful to Chromium/Blink developers. (Suggested by skobes@ and
pdr@.)

If this LGTY, I'll find a chrome/browser/ui/ owner to review it.

[pdr., 2015-02-13 22:58:45]

On 2015/02/13 at 22:52:53, jbroman wrote:
> Possible mitigation to discourage enterprises from relying on this flag,
without making it less useful to Chromium/Blink developers. (Suggested by
skobes@ and pdr@.)
> 
> If this LGTY, I'll find a chrome/browser/ui/ owner to review it.

LGTM, I think this is the right approach.

@eseidel, thanks for catching this. Was this inspired by your experience with
--enable-show-modal-dialog?

[eseidel, 2015-02-13 23:27:23]

Inspired by abarth's long-time objection to this feature.

There is some history here, from when I attempted to autogen the
WebRuntimeEnabledFeatures layer, only to find that I couldn't really make
public/Web APIs autogenerated.  This solution was proposed and abarth raised
similar concerns at the time.

I think this should be OK.  Although I also seem to remember an internal study
at some point of the % of users which had a butter-bar open at all times being
very high. :)  So YMMV.

[jbroman, 2015-02-17 15:31:15]

jbroman@chromium.org changed reviewers:
+ sky@chromium.org

[jbroman, 2015-02-17 15:31:15]

+sky for chrome/browser/ui/OWNERS

[sky, 2015-02-19 15:44:29]

LGTM - if these are only for internal development should they be ifdef'd out in
official and/or release builds?

[jbroman, 2015-02-19 19:20:41]

On 2015/02/19 15:44:29, sky wrote:
> LGTM - if these are only for internal development should they be ifdef'd out
in
> official and/or release builds?

Thought about it, but I'm inclined to leave it in those builds. I've used
previous for-development flags as a triaging aid (does turning this knob make
the bug go away?), and this infobar ought to be enough to discourage anyone from
relying on it for real-world usage.

[jbroman, 2015-02-19 19:20:45]

The CQ bit was checked by jbroman@chromium.org

[commit-bot: I haz the power, 2015-02-19 19:21:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/928593004/1

[commit-bot: I haz the power, 2015-02-19 19:25:51]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-19 19:26:13]

Patchset 1 (id:??) landed as
https://crrev.com/446bce0a188c000a4b77e51fbc66af1fd22e0398
Cr-Commit-Position: refs/heads/master@{#317098}

[Nico, 2015-02-19 21:58:56]

On 2015/02/19 19:20:41, jbroman wrote:
> On 2015/02/19 15:44:29, sky wrote:
> > LGTM - if these are only for internal development should they be ifdef'd out
> in
> > official and/or release builds?
> 
> Thought about it, but I'm inclined to leave it in those builds. I've used
> previous for-development flags as a triaging aid (does turning this knob make
> the bug go away?), and this infobar ought to be enough to discourage anyone
from
> relying on it for real-world usage.

I'm not sure I buy that the infobar will block determined folks from using this
flag.

I'm also not sure if this helps with triaging, as the new fancy is disabled by
default, and "do things work if you --enable-new-feature?" probably won't yield
useful data.

Unless there's reason that actually suggests that this is needed in release
builds, I too think this should be compiled out in branded builds.

[pdr., 2015-02-19 22:36:15]

On 2015/02/19 at 21:58:56, thakis wrote:
> On 2015/02/19 19:20:41, jbroman wrote:
> > On 2015/02/19 15:44:29, sky wrote:
> > > LGTM - if these are only for internal development should they be ifdef'd
out
> > in
> > > official and/or release builds?
> > 
> > Thought about it, but I'm inclined to leave it in those builds. I've used
> > previous for-development flags as a triaging aid (does turning this knob
make
> > the bug go away?), and this infobar ought to be enough to discourage anyone
from
> > relying on it for real-world usage.
> 
> I'm not sure I buy that the infobar will block determined folks from using
this flag.

The infobar is for liability more than preventing usage: we don't want
enterprise customers to depend on in-development features.

> 
> I'm also not sure if this helps with triaging, as the new fancy is disabled by
default, and "do things work if you --enable-new-feature?" probably won't yield
useful data.
> 
> Unless there's reason that actually suggests that this is needed in release
builds, I too think this should be compiled out in branded builds.

This change doesn't affect what's compiled in the binary, just what's exposed to
the command line. This change will reduce the plumbing needed for many
intent-to-implement features which reduces friction. I am less worried about an
infobar'd runtime enabled feature flag than I am our sticky infobar-less
about://flags settings.