[webkit-dev] Experimental features enabled at runtime

[Brady Eidson]

> On Nov 5, 2016, at 3:52 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> 
> 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.

This section was only added 7 months ago in https://trac.webkit.org/changeset/199700 and I don't recall seeing the discussions that decided this rule.

Are they in webkit-dev archives or a bugzilla somewhere?

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

On Mac we have this as well in the form of WKPreferences.

_WKExperimentalFeatures is different. The app does not need to know about a feature ahead of time. The API automatically enumerates the list of features.

All the app needs to do is call [WKPreferences _experimentalFeatures] to get a set of all experimental features.
It can then inspect each feature and turn it on or off as needed.

If you launch Safari Technology Preview, for example,  and go to the "Develop -> Experimental Features", you'll see each feature listed.
Behind the scenes, that menu is 100% driven by WebKit and the set of features this API enumerates.

If WebKit engineers add a new "experimental feature", it automatically shows up in the list of features as exposed by the WKPreferences API, and therefore automatically shows up in Safari's menu.

This is very different from WebPreferences and WebKitSettings, which have lots and lots of methods, one set of methods per feature, and each method must be adopted by new builds of a client.

> Of course I agree it makes sense to have non-experimental settings that can be
> enabled or disabled at runtime.

Again, the word "experimental" here is ill defined and I don't think we're all on a common ground with it.

Here's one possible breakdown one can make for the lifecycle of a new web-exposed feature under development:

1 - Development just started in WebKit. It's nowhere near working yet. The feature has a runtime-enabled flag that is off by default, but is also behind a compile-time flag that might be off by default, or off for all but one platform.

2 - The feature works well enough that it's meaningful for WebKit dev to all test it and see how it affects stability of the rest of the engine. It might also be far enough along that letting cutting-edge web devs play with it would give great feedback. The compile-time flag is now on by default for everybody, but the runtime enabled flag is still off.

3 - The feature is "complete", and most known bugs with it are squashed. It's still "new," though, and hasn't shipped yet in a major stable project. It should be on for all of WebKit's targets as well as "development" products from vendors.
At this point the runtime-flag should probably be enabled by default. But if a vendor doesn't want to be the first to ship, they can disable it by default in their product. Or if the vendor wants to provide a switch for their users to change at runtime, they use API to do so.

4 - The feature is so well baked and so embedded in the web platform that it no longer makes any sense to ship a web engine without it. At this point the runtime flag should be removed altogether.

The _WKExperimentalFeatures API provides for both #2 (disabled by default) and #3 (enabled by default) features.
If the API was called something like _WKRuntimeEnabledFeatures instead I feel like a lot of this discussion would have self resolved. Let's pretend it was called that. :)

> It sounds like Cocoa API changes are required to support this?

Cocoa API already exists for this, in the form of _WKExperimentalFeature.

GTK+ could consider adding something like this, as well, to support clients that want an API-enumerable list of such features!

>> 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.

As mentioned, we already have WKPreferences for many settings as well, with specific per-setting methods.

> We can't use it for all settings, though, because
> we don't want every setting to become API forever,

We don't either! Exactly!

> and we don't want
> non-GTK+ developers to have to remember to add GTK+ API for every new
> runtime feature.

We also don't want to add new API for each specific feature that should be runtime-enablable for now, but possibly not in the future.
> 
> 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.

Sure.

> 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?

I think there's two things going on here.

1 - As mentioned in my first reply, I think the word "experimental" carries a lot of baggage that doesn't actually apply here. And in that regard I believe the _WKExperimentalFeature API along with the "FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE" section of WebPreferenceDefinitions.h was poorly named.

2 - When it comes to "runtime enabled, web exposed features", we absolutely have gone both ways with Safari in the past.
That is, some features that were less-than-ideally stable and/or still under heavy development *were* enabled in a shipping version of Safari,
and some features that were very stable and most development was completely would be *disabled* in a shipping version of Safari.

> 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.

I think the WebKit project as a whole would be hard pressed to codify rules that apply to all "different types of releases" that *all* vendors want to maintain.

Thanks,
 Brady