This is a step toward the semantics described in https://bugs.webkit.org/show_bug.cgi?id=222885, where each feature is marked with a "status" label that indicates how it is intended to be used, and whether it should be surfaced in browser UI.
rdar://92112770
Pull request: https://github.com/WebKit/WebKit/pull/6497
Pull request: https://github.com/WebKit/WebKit/pull/6945
Committed 257166@main (429cc4c78986): <https://commits.webkit.org/257166@main> Reviewed commits have been landed. Closing PR #6945 and removing active labels.
Re-opening for pull request https://github.com/WebKit/WebKit/pull/7081
Committed 258413@main (4663bc861b1e): <https://commits.webkit.org/258413@main> Reviewed commits have been landed. Closing PR #7081 and removing active labels.
Re-opened since this is blocked by bug 250065
Pull request: https://github.com/WebKit/WebKit/pull/8206
Committed 258448@main (9def6e6f0258): <https://commits.webkit.org/258448@main> Reviewed commits have been landed. Closing PR #8206 and removing active labels.
While we're refactoring WebPreferences, would it be worth integrating JSC feature flags defined in OptionList.h, or providing a simple cross-port way to have a WebCore feature imply a JSC feature? I've been struggling to get this to work for the one-off case of WebAPIsInShadowRealmEnabled implying JSC_useShadowRealm, it would be super helpful if there were a simpler way to do this for future JS features.
> While we're refactoring WebPreferences, would it be worth integrating JSC feature flags defined in OptionList.h, or providing a simple cross-port way to have a WebCore feature imply a JSC feature? The trouble with JSC options is that (as I understand it), its options are loaded before WebCore is initialized, and the config is frozen after the VM is instantiated. But I agree that it would be really nice to have a better way to pass things down.
(In reply to Elliott Williams from comment #11) > > While we're refactoring WebPreferences, would it be worth integrating JSC feature flags defined in OptionList.h, or providing a simple cross-port way to have a WebCore feature imply a JSC feature? > > The trouble with JSC options is that (as I understand it), its options are > loaded before WebCore is initialized, and the config is frozen after the VM > is instantiated. But I agree that it would be really nice to have a better > way to pass things down. My current thinking is that this comes down to individual ports accessing shared WebPreferences in a UI process, and using that to modify launch options for the web process which would in turn affect JSC's configuration - but since I primarily work on JSC, I'm not sure what would be needed to achieve this.
(In reply to Caitlin Potter (:caitp) from comment #12) > > My current thinking is that this comes down to individual ports accessing > shared WebPreferences in a UI process, and using that to modify launch > options for the web process which would in turn affect JSC's configuration - > but since I primarily work on JSC, I'm not sure what would be needed to > achieve this. OK, this makes sense! I think it would work. Filed https://bugs.webkit.org/show_bug.cgi?id=250539 to track this.