On Wed, Sep 12, 2018 at 5:48 PM Dean Jackson <d...@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.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
