PSA: Controlling runtime enabled features from the command line

[Jeremy Roman]

As of a week ago, you can now set runtime-enabled features from the command line.

content provides two switches which can be used to turn runtime enabled features on or off, intended for use during development. They are exposed by both content_shell and chrome.

--enable-blink-features=SomeNewFeature,SomeOtherNewFeature
--disable-blink-features=SomeOldFeature

After applying most other feature settings, the features requested feature settings (comma-separated) are changed. "disable" is applied later (and takes precedence), regardless of the order the switches appear on the command line. These switches only affects Blink's state. Some features may need code to be switched on in Chromium as well; in this case, a specific flag is still required.

This is intended to alleviate the need to plumb a flag through Chromium to toggle small Blink features during development, especially before they're ready to have their status changed (to test, experimental, or stable, as appropriate).

[Yoav Weiss]

Woot! That's awesome!!!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Eric Seidel]

Blink may end up regretting this feature. Clients (read: enterprise)
may now try to depend on arbitrary combinations of Blink features.
Where as previously Blink's feature configuration was largely hidden
from customers.

Time will tell.

[Nico Weber]

On Fri, Feb 13, 2015 at 2:04 PM, Eric Seidel <ese...@chromium.org> wrote:

Blink may end up regretting this feature.  Clients (read: enterprise)
may now try to depend on arbitrary combinations of Blink features.
Where as previously Blink's feature configuration was largely hidden
from customers.

Maybe the flag could have an effect only in unbranded builds, to mitigate this concern?

[Steve Kobes]

Or put up a butter bar warning like we do for --no-sandbox?

[Mounir Lamouri]

On Sat, 14 Feb 2015, at 01:54, Jeremy Roman wrote:
> As of a week ago <https://codereview.chromium.org/898483004/>, you can

Is it intended to be used to enable features from Chromium for tests for
example?

-- Mounir

[Jeremy Roman]

I'm not quite sure what you're asking. I'd summarize it as toggling Blink features from the command line during development.

If you want to control Chromium features from the command line, I'd just add a switch in Chromium as usual (if appropriate).

If you want to control Blink features from Chromium code (incl. Chromium tests), blink::WebRuntimeFeatures (and the code that calls it) continues to be appropriate.

If you want to control Blink features from Blink layout tests, it depends on your use case. In a lot of cases, just marking the REF as status=test is sufficient.

[Mounir Lamouri]

I meant controlling Blink features from a browser test and other
Chromium tests. The current situation requires quite some plumbing.
Being able to use --enable-blink-features would save some line of code
and would also solve one problem with WebRuntimeFeatures where it's not
clear which flags are meant for testing and which are meant for
production use. Is there a downside I'm missing?

-- Mounir

[Jeremy Roman]

I'm not really familiar with browser tests. Maybe someone with that experience could weigh in on whether that's appropriate.

[Eric Seidel]

Every time a browser_test depends on a non-default Blink feature an
angel looses its wings.

Also, you create a cross-repository dependency meaning a 2-sided patch
is required to remove said dependency if the flag were ever removed.

Blink features should only ever be tested inside Blink using Blink
tests (layout tests) IMO. But that's really up to the current Blink
owners rather than I...

[Jeremy Roman]

Done.

https://chromium.googlesource.com/chromium/src.git/+/446bce0a188c000a4b77e51fbc66af1fd22e0398