[webkit-dev] Experimental features enabled at runtime

Michael Catanzaro mcatanzaro at igalia.com
Sat Nov 5 15:52:34 PDT 2016

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

> 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!)


More information about the webkit-dev mailing list