Hi. What status should be used for: "Enabled by default on most platforms except those we’ve decided not to support or if a local system dependency can’t be met but feature is still ready for general use, but UI to toggle the feature remains to support debugging, A/B testing." That defaultValue could be ignored in the future seems a regression and doesn’t address some existing use cases. Thanks Jean-Yves
On 10 Jan 2023, at 9:11 am, Elliott Williams via webkit-dev <webkit-dev@lists.webkit.org> wrote:
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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev