Hi webkit-dev,
Brent (CC’d) and I are rolling out changes to how we represent feature flags in
WebKit. As of https://commits.webkit.org/258448@main, the WebPreferences*.yaml
files have been merged to one feature list:
Source/WTF/Preferences/UnifiedWebPreferences.yaml
Instead of having separate lists of experimental features, internal debug
features, etc., each feature now has a `status` field. A feature’s status
determines which UIs it is visible in (if any), and in the future will control
its default value. Right now, these are the semantic meanings of the features
status:
embedder Adjust WebKit behavior for embedding application needs.
unstable Feature in active development. Unfinished, no promise
it is usable or safe.
internal Tools for debugging the WebKit engine. Not generally
useful to web developers.
developer Tools for web developers.
testable Enabled by default in test infrastructure, but not
ready to ship yet. Should be accessible for STP users who wish to activate them
for testing and feedback.
preview Enabled by default in Safari Technology Preview, but not
considered ready to ship yet.
stable Enabled by default and ready for general use, but UI to toggle
the feature remains to support debugging, A/B testing.
shipping Enabled by default and ready for general use, but no UI
to toggle. In general, will be removed 1 year after the change to shipping.
When you’re adding or changing features, our source generator will force you to
pick one of these status. The “public-facing” statuses (developer, testable,
preview, stable) are visible from the various “experimental features” call
sites declared by WebKit, and the rest are exposed as “internal debug
features”. And I’m adding an additional WebPreferences API which lists all
features, so clients can avoid the experimental/internal-debug dichotomy going
forward.
There’s one topic I’d like feedback on, which pertains to the non-Apple ports:
Some features don’t seem to have the same “status” on all platforms. For
example, pdf.js has been enabled for GTK and WPE for some time now, and should
probably be considered `stable` on those platforms. But it’s off by default on
Apple platforms, where it should be no more than `testable`. How do we resolve
discrepancies like these? We could:
- allow a feature’s status to be platform-conditional
- allow each port to decide whether a feature is on or off by default
(regardless of its status)
- do nothing, and require clients to change feature statuses at runtime in
order to modify default behavior
I’d like to eventually use the committed feature list to power
https://webkit.org/status/, which makes me want to avoid having
platform-conditional statuses. It would also be nice for feature statuses to be
a global truth, helping us speak collectively about what web platform features
are supported.
Elliott
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
