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!