Bug 247926 – Add a 'status' field to feature flags denoting their use case

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

[Elliott Williams]

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.

[Elliott Williams]

rdar://92112770

[Elliott Williams]

Pull request: https://github.com/WebKit/WebKit/pull/6497

[Elliott Williams]

Pull request: https://github.com/WebKit/WebKit/pull/6945

[EWS]

Committed 257166@main (429cc4c78986): <https://commits.webkit.org/257166@main>

Reviewed commits have been landed. Closing PR #6945 and removing active labels.

[Elliott Williams]

Re-opening for pull request https://github.com/WebKit/WebKit/pull/7081

[EWS]

Committed 258413@main (4663bc861b1e): <https://commits.webkit.org/258413@main>

Reviewed commits have been landed. Closing PR #7081 and removing active labels.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 250065

[Elliott Williams]

Pull request: https://github.com/WebKit/WebKit/pull/8206

[EWS]

Committed 258448@main (9def6e6f0258): <https://commits.webkit.org/258448@main>

Reviewed commits have been landed. Closing PR #8206 and removing active labels.

[Caitlin Potter (:caitp)]

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.

[Elliott Williams]

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

[Caitlin Potter (:caitp)]

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

[Elliott Williams]

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