[webkit-dev] Settings and Testing (Settings, RuntimeEnabledFeatures, WebPreferences)
Joseph Pecoraro
pecoraro at apple.com
Fri Jan 20 19:14:23 PST 2017
Toggling settings in tests is a confusing area, with multiple (sometimes conflicting) ways to modify settings.
After cleaning things up a bit in r211006 I wanted to document my understanding of the patterns I see right now. Much of this was new to me so others may find it useful.
Different Types of Settings:
• RuntimeEnabledFeatures (WebCore)
- Should be for features that have Web Exposed APIs that will only be exposed if the feature is enabled
- Should be for features that must be toggled before a page has loaded, since after a page load may be too late for EnabledAtRuntime bindings
• Settings (WebCore)
- All other settings that change engine behavior
- Okay to toggle at any time and WebCore often respects the setting immediately
• WebPreferences (WebKit, WebKit2)
- API level Toggles for the above settings
- Toggles for WebKit level behavior (e.g. Tabbing between links behavior)
- Ports may have different default values for features
Policies for Settings in LayoutTests:
• TestRunners (WebKitTestRunner / DumpRenderTree)
- Should set up a consistent environment before each test
- Ports have different defaults, so having TestRunner make things consistent seems reasonable
- WTR: TestController::resetPreferencesToConsistentValues
- DRT: resetWebPreferencesToConsistentValues
- Should enable Experimental features for tests
- Since we allow users to enable these features they should be enabled and get maximum testing
- WTR: WKPreferencesEnableAllExperimentalFeatures
- DRT: enableExperimentalFeatures
• If a test wants to change a Setting:
- Use: internals.settings.setFoo(value);
- Settings in Settings.in are autogenerated, others are added to InternalSettings as needed
- InternalSettings handles resetting modifications before the next test
• If a test wants to change a RuntimeEnabledFeature:
- No set pattern.
- Some tests use internals.settings but this seems inappropriate, since the page has already loaded
- Some tests use the special comment syntax parsed by TestRunners; this makes sense, but would not be good for imported tests
• If a test wants to change a WebPreference / WebKit level setting:
- Use: testRunner.someMethod(value);
- Avoid: testRunner.overridePreference(preferenceKey, value);
- TestRunners should reset these back to a consistent value before the next test
Let me know if you think anything is inaccurate or if you have ideas to simplify / improve.
- Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170120/724a178c/attachment.html>
More information about the webkit-dev
mailing list