Bug 117870 – Kill RuntimeEnabledFeatures class

• Status: ASSIGNED
• Component: Bindings

[Chris Dumez]

The RuntimeEnabledFeatures class is barely used currently and is manually written. It was mostly used by the Chromium port to support the [EnabledAtRuntime] IDL extended attribute.

We can leverage WebCore Settings class instead which is widely used and automatically generated.

We currently have 2 IDL extended attribute to enable features at runtime:
- [EnabledAtRuntime] backed by the RuntimeEnabledFeatures class
- [EnabledBySetting] backed by the Settings class

I believe we should keep the [EnabledAtRuntime] IDL attribute because it has been supported for a long time, people know about it and it is used by Blink. However, I think we should make [EnabledAtRuntime] use Settings instead of RuntimeEnabledFeatures.

[Chris Dumez]

I am not sure yet if this is a viable solution and I need to investigate more. Can we always access the Settings from the bindings code?

For JSDOMWindow, we currently access the settings via impl()->frame()->settings() but for other types, I believe we may not easily get access to the frame's settings.

[Geoffrey Garen]

FWIW, JavaScript objects can access their window through structure()->globalObject().

[Chris Dumez]

(In reply to comment #2)
> FWIW, JavaScript objects can access their window through structure()->globalObject().

Thanks for the info Geoffrey.

Another issue is that not all [EnabledAtRuntime] are controlled by Setting-like flags. For e.g. the media features call MediaPlayer::isAvailable(), sql database features rely on DatabaseManager::manager().isAvailable().