Hi Brady! On Sat, 2016-11-05 at 11:04 -0700, Brady Eidson wrote: > This has come up in Apple, where some people assume that the fact > they're called "Experimental" features means they are still under > heavy development or in some way unstable or potentially harmful. > > I don't believe that is actually the case.
Surely if the feature is stable, then it should be moved to the non- experimental section of WebPreferencesDefinitions.h. Stable features shouldn't be touched by FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE. > Ignoring the name for a moment, the _WKExperimentalFeature API really > does precisely two things: > 1 - Exposes an enumerable set of runtime-enablable features. > 2 - Exposes an API to turn each of them on or off. > > That's it. > > For a long time we've had "runtime enabled features" in the project > with no way to expose them as an enumerable set to the API client. > The API was named "Experimental" feature, I think, because at first > only "under heavy development" features that were not ready to be > enabled at runtime adopted the mechanism. This is surprising to me! We've had API for this in WebKitGTK+ for a long time (WebKitSettings.h), and there's extensive cross-platform infrastructure to support it (WebPreferencesDefinitions.h). Of course I agree it makes sense to have non-experimental settings that can be enabled or disabled at runtime. It sounds like Cocoa API changes are required to support this? > > They should be enabled by Safari if they're desired there. > > The ones that have been deemed fit to be "enabled by default" for > testing should be on by default for testing in places other than > Safari, such as MiniBrowser and 3rd party WebKit apps. Good point. > I strongly object to reverting all _WKExperimentalFeatures to "off by > default" > > I strong support adding port-specific defaults. > > As a different conversation, I also support renaming the API to > something that doesn't impart the baggage of an "under development" > or "unstable" feature. Well we already have GTK+-specific defaults for runtime settings in WebKitSettings.cpp, but only for the subset of the settings that are exposed in our API. We can't use it for all settings, though, because we don't want every setting to become API forever, and we don't want non-GTK+ developers to have to remember to add GTK+ API for every new runtime feature. I'm not actually sure that we do need port-specific defaults for runtime settings. I think that in general, we really want to use the same defaults as Apple. You know better than we what the settings do and how stable they are. The exception would be when settings need platform-specific implementation, but in that case I'd expect the options would have to be guarded by build flags, and we already have port-specific defaults for build flags. But we surely don't want anything labeled experimental to be enabled by default for end users. I really doubt you would want such features enabled in stable versions of Safari either, right? Maybe what we really need is one set of defaults that are appropriate for development (our bots, ENABLE(DEVELOPER_MODE), Safari Tech Preview, etc.) and a different set of defaults that are appropriate for stable releases and end users. We already have this for build options (FeatureList.pm for developer settings where we enable experimental stuff, WebKitFeatures.cmake for end-user settings where we do not) but we have no analog of this for runtime options. So one possibility would be to have two lists of default values of experimental features: one used in ENABLE(DEVELOPER_MODE) which turns on all the new fun stuff, and one for !ENABLE(DEVELOPER_MODE) which is more conservative. Probably that would work for all ports without requiring port-specific defaults? (If not, I guess we'll just have to add port-specific defaults after all, but hopefully we don't need to!) Michael _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
