Bug 164367 – Experimental features should not be enabled by default

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Michael Catanzaro]

We have now done three stable WebKitGTK+ releases with a bunch of experimental features enabled by default.

Experimental features must not be enabled by default. If these are desired for Safari Technology Preview, then Safari should enable them, that's what the runtime settings API is for.

[Michael Catanzaro]

Created attachment 293764 [details]
Patch

[Michael Catanzaro]

(Ryosuke, you might want to remove Custom Elements from here if it's ready for prime time?)

[Michael Catanzaro]

(In reply to comment #0)
> Experimental features must not be enabled by default. If these are desired
> for Safari Technology Preview, then Safari should enable them, that's what
> the runtime settings API is for.

To be clear: it's understandable you don't have UI to toggle these yet. You can override the default value in Safari Technology Preview unconditionally in the meantime, but the WebKit project default should be sane to not screw up other ports.

[Ryosuke Niwa]

Comment on attachment 293764 [details]
Patch

I don't think disabling these features by default is okay.

We need to figure out why these experimental features are enabled by default on GTK+ port and fix that instead.

[Michael Catanzaro]

(In reply to comment #4) 
> We need to figure out why these experimental features are enabled by default
> on GTK+ port and fix that instead.

They're enabled because this is the file in which we define the default values of WebKit features. ;)

[Brady Eidson]

I've replied in the email thread on webkit-dev strongly objecting to reverting all features to disabled-by-default.

Even if you somehow convince Ryosuke to r+ this patch, my review is a standing r-.

We should resolve this on webkit-dev.

[Ryosuke Niwa]

Perhaps the defaults need to be defined per port?

[Darin Adler]

It is bad we’ve turned these on in for the GTK port even though the maintainers of that port don’t want them on. Please lets quickly agree to something, even if it’s not rolling back these defaults.

Brady, do you have ideas about what to do short term?

[Brady Eidson]

I think a perfectly fine short term solution would be to have a copy of these prefs for non-Apple ports.  There's not that many of them.

[Michael Catanzaro]

Created attachment 294153 [details]
Patch

[Michael Catanzaro]

Ryosuke, Brady, Darin, what do you think of this approach? (Note that it removes Custom Elements from the experimental features list; is that desired?)

My changelog entry tries to nod towards Brady's desire for an enumerable features API that's not named experimental features, though my patch does not actually address that at all, leaving it as future work for interested developers.

[Michael Catanzaro]

In particular, note that I'm trying to avoid port-specific defaults here, so that Apple developers who know best have to think about what the value should be for other ports here. :) It's still possible to define port-specific defaults at the top of the file with all the other port-specific defaults when they're really needed.

[Darin Adler]

Comment on attachment 294153 [details]
Patch

Yes, to me this looks like a good step to take now. I’m sure we can make additional improvements and refinements in the future.

[WebKit Commit Bot]

Comment on attachment 294153 [details]
Patch

Clearing flags on attachment: 294153

Committed r208495: <http://trac.webkit.org/changeset/208495>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.