[webkit-dev] Experimental features enabled at runtime

[Ryosuke Niwa]

On Sat, 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.
>
> > 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?
>

I DO want to enable experimental features to be enabled in Safari
Technology Preview and WebKit nightly builds by default because that's sort
of the whole point of having those versions of Safari in the first place.

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.


That makes sense.  Ideally, FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE
is only used for features that need to be enabled in those "beta" or
"developer" versions of each port's browser.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20161105/60ff4d70/attachment.html>