Bug 247926
| Summary: | Add a 'status' field to feature flags denoting their use case | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Elliott Williams <emw> |
| Component: | WebKit Misc. | Assignee: | Elliott Williams <emw> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | caitp, commit-queue, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 250065, 250066, 255547 | ||
| Bug Blocks: | 222885, 250106, 250539, 250156, 250164 | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.