247926 2022-11-14 16:46:17 -0800 Add a 'status' field to feature flags denoting their use case 2023-04-17 14:15:11 -0700 1 1 1 Unclassified WebKit WebKit Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 250065 250066 255547 222885 250106 250539 250156 250164 1 emw emw caitp commit-queue webkit-bug-importer oldest_to_newest 1912467 0 emw 2022-11-14 16:46:17 -0800 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. 1912468 1 emw 2022-11-14 16:46:31 -0800 rdar://92112770 1912472 2 emw 2022-11-14 17:19:02 -0800 Pull request: https://github.com/WebKit/WebKit/pull/6497 1915434 3 emw 2022-11-29 15:15:35 -0800 Pull request: https://github.com/WebKit/WebKit/pull/6945 1915525 4 ews-feeder 2022-11-29 22:30:38 -0800 Committed 257166@main (429cc4c78986): <https://commits.webkit.org/257166@main> Reviewed commits have been landed. Closing PR #6945 and removing active labels. 1916288 5 emw 2022-12-02 12:05:13 -0800 Re-opening for pull request https://github.com/WebKit/WebKit/pull/7081 1922767 6 ews-feeder 2023-01-03 17:56:24 -0800 Committed 258413@main (4663bc861b1e): <https://commits.webkit.org/258413@main> Reviewed commits have been landed. Closing PR #7081 and removing active labels. 1922802 7 commit-queue 2023-01-03 23:11:45 -0800 Re-opened since this is blocked by bug 250065 1922929 8 emw 2023-01-04 12:23:47 -0800 Pull request: https://github.com/WebKit/WebKit/pull/8206 1922974 9 ews-feeder 2023-01-04 13:46:03 -0800 Committed 258448@main (9def6e6f0258): <https://commits.webkit.org/258448@main> Reviewed commits have been landed. Closing PR #8206 and removing active labels. 1924226 10 caitp 2023-01-09 16:58:40 -0800 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. 1924231 11 emw 2023-01-09 17:17:28 -0800 > 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. 1924409 12 caitp 2023-01-10 07:35:46 -0800 (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. 1925210 13 emw 2023-01-12 18:20:16 -0800 (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.