| 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 | ||
|
Description
Elliott Williams
2022-11-14 16:46:17 PST
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. |