PSA: Runtime Features system is now auto-generated from a .in file.

[Eric Seidel]

TL;DR: If you're adding/removing runtime-guarded features, use
RuntimeEnabledFeatures.in:
https://src.chromium.org/viewvc/blink/trunk/Source/core/page/RuntimeEnabledFeatures.in



As of http://crbug.com/237740 the entire RuntimeEnabledFeature system
in Blink is autogenerated. (Almost) all responsibility for managing
which flags are on has moved from Content to Blink.

All features are now off by default, but based on their "status"
('stable', 'experimental', 'test') are automatically enabled in
Chrome, DRT, etc appropriately.


I expect most features will start out in "test", meaning they will be
on in DRT/ContentShell by default, and off everywhere else.

Eventually when they're ready for web-developer testing they'll be on
for testing, and enable-able in Chrome with the
--experimental-webkit-features flag.

Finally once they've cleared "intent to ship" and should be on always,
they'll move to "stable".

Most features will want to stay in "stable" for a bit after shipping
so they can easily be turned off if a critical security bug is found,
or the like. After a while, I recommend removing the runtime flag
entirely.


If you look at the file today, you'll see lots of "stable" features,
almost all of which could probably have their runtime flags removed.

Similarly you'll see many features without a status. These are off
everywhere. Some of them have some (error ridden) code in Content to
turn them on in certain cases. I would encourage all features to move
to the status-based system in the near term.


Our idl files support an [EnabledAtRuntime=featureName] decorator on
interfaces, methods and attributes.

Similarly our .in files will soon support an EnabledAtRuntime-like
decorator as well, although those patches are still in flight.

Hopefully this helps. Comments/questions/patches welcome!

[Marshall Greenblatt]

Is there still a way to enable/disable these runtime features programmatically? Downstream users of Chromium/Blink may want to ship with a different set of features enabled.

Thanks,

Marshall

 

[Adam Barth]

Yes, they're still exposed via the WebRuntimeFeatures API individually, as before.

Adam

[Eric Seidel]

WebRuntimeFeatures is not currently autogenerated for build complexity
reasons. (I have a script which can do it, but don't plan to make it
part of the build).

I would encourage all downstream users to just call
WebRuntimeFeatures::enableStableFeatures() and possibly
enableExperimentalFeatures() and then tweak from there.

For example, RenderThreadImpl calls various
WebRuntimeFeatures::enableFoo(false); to disable features which are
unavailable on Android:

http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/render_thread_impl.cc?revision=198418
771 WebRuntimeFeatures::enableStableFeatures(true);
772
773 if (command_line.HasSwitch(switches::kEnableExperimentalWebKitFeatures))
774 WebRuntimeFeatures::enableExperimentalFeatures(true);
775
776 AdjustRuntimeFeatureDefaultsForPlatform();
777 AdjustRuntimeFeaturesFromArgs(command_line);

Blink's stable/experimental lists represent what Blink believes are
stable, not necessarily reflecting Content's platform constraints
(since Blink is largely platform agnostistic).

[Adam Barth]

You should also keep in mind that features that are not marked as stable are likely to be removed if we decide not to ship them.  The point of the "intent to ship" discussions is for the project to agree on which features we're committed to for the long haul.

Adam

[Eric Seidel]

It's been pointed out to me that I forgot to mention that
"experimental" features are enabled both during testing (in
DRT/ContentShell) as well as in Chrome, etc. when
--experimental-webkit-features is set in about:flags.

I'm glad to see that there have already been several patches posted to
make previously "off" features into "test" features, and remove all
the per-layout-tests settings enabling code!