[webkit-dev] Experimental and (new) Internal feature flags

[Ali Juma]

On Wed, Sep 12, 2018 at 5:48 PM Dean Jackson <dino at apple.com> wrote:

> I just added support for a new category of WebKit2 preference: internal
> debug.
>
> The motivating factor was that people were abusing experimental features
> to add flags for anything they wanted to toggle at runtime, even if our
> users would have no idea what it meant (nor should they ever toggle it).
> Internal features are not public-facing.
>
> My next task will be to remove the ability to set a default value for
> experimental features. They will default to be off (if it really is
> experimental, it shouldn't be on by default). This will apply even to tests
> - see below for how to turn them on at runtime inside WKTR.
>
> Documented here:
> https://trac.webkit.org/wiki/ExperimentalAndInternalFeatureFlags
>
> WebKit provides a way to expose a feature flag to a client application at
> runtime, and have that application toggle the feature. This lets us to
> start work on experimental features without fully exposing them to the Web,
> but allows Web developers to turn them on and test. There are two types of
> exposed features: Experimental and Internal Debug.
>
> The configuration file WebPreferences.yaml controls these features. Just
> set the category value to experimental or internal. Note that you should
> also provide a nice human-understandable description and name.
>
> These are only exposed by WebKit2. If you want your feature to be toggled
> via WebKit1 you'll have to manually add more code.
>
> Experimental Features
> ----
>
> These features are designed for Web developers, and are exposed via
> Safari's Develop menu as well as MiniBrowser.
>
> Internal Debug Features
> ----
>
> These features are designed for WebKit developers, and are exposed via
> Safari's secret-but-not-really Debug menu. We do not expect Web developers
> to change these settings. They are also exposed by MiniBrowser.
>
> Which should I use?
> ----
>
> If a Web developer wouldn't understand what the feature is by name, or it
> is just for internal testing, then you should use an internal feature. For
> example, we don't want users to disable Service Workers, and almost no one
> would know what MDSN ICE Candidates are.
>
> What about testing?
> ----
>
> You can turn both experimental and internal features on via headers in
> WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For
> example...
>
> <!-- webkit-test-runner [
> experimental:WebAnimationsCSSIntegrationEnabled=true ] -->
>

Is there a plan for how to handle web platform tests (where we can't add
such a header)?

Currently, WebKitTestRunner enables all experimental features in tests
(including those disabled by default), so adding an experimental feature
(even one that's disabled by default) is a convenient way to get web
platform test coverage for the feature. If WebKitTestRunner will no longer
do that, we'll need some other way to keep these tests running.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180912/e0a18fd2/attachment.html>