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.
Created attachment 293764 [details] Patch
(Ryosuke, you might want to remove Custom Elements from here if it's ready for prime time?)
(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.
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.
(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. ;)
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.
Perhaps the defaults need to be defined per port?
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?
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.
Created attachment 294153 [details] Patch
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.
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.
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.
Comment on attachment 294153 [details] Patch Clearing flags on attachment: 294153 Committed r208495: <http://trac.webkit.org/changeset/208495>
All reviewed patches have been landed. Closing bug.