Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend
Created attachment 411779 [details] Patch
Comment on attachment 411779 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=411779&action=review r=me assuming it builds and passes tests > Source/WTF/ChangeLog:3 > + Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend This is important for the non-testing API and SPI, and the features we expose for tweaking in Safari Technology Preview. But for *testing* interfaces, do we really need to carefully control what is exposed? Why not expose it all for testing? I suppose there could be a downside if someone unwisely tweaks a setting in a test and we don’t notice that? I can’t quite tell our intent about that, though. Maybe some documentation overview could help make that intent clear?
(In reply to Darin Adler from comment #2) > Comment on attachment 411779 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=411779&action=review > > r=me assuming it builds and passes tests > > > Source/WTF/ChangeLog:3 > > + Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend > > This is important for the non-testing API and SPI, and the features we > expose for tweaking in Safari Technology Preview. But for *testing* > interfaces, do we really need to carefully control what is exposed? Why not > expose it all for testing? I suppose there could be a downside if someone > unwisely tweaks a setting in a test and we don’t notice that? I can’t quite > tell our intent about that, though. Maybe some documentation overview could > help make that intent clear? The rationale for changing it for testing comes down to a conversation with Simon I had yesterday. My initial desire was to expose everything for testing, but when I did that, I ran into an issue with tests like compositing/layer-creation/absolute-in-async-overflow-scroll.html, which specify <!-- webkit-test-runner [ internal:AsyncOverflowScrollingEnabled=true ] -->. Simon would like this test to continue to have AsyncOverflowScrollingEnabled enabled for WebKit2, and disabled for WebKitLegacy. We went back and forth on whether it was really valuable to have these tests run for WebKitLegacy, or whether it would make more sense to have explicit negative tests of tests like these where <!-- webkit-test-runner [ internal:AsyncOverflowScrollingEnabled=false ] --> was used. Ultimately, in attempting to limit behavior change while getting this working, I am ok with this kind of odd behavior, where we just ignore the header command for WebKitLegacy, for now, as it is the status quo, but I would like to relitigate it once all the pieces are in place.
Created attachment 411825 [details] Patch
Committed r268719: <https://trac.webkit.org/changeset/268719> All reviewed patches have been landed. Closing bug and clearing flags on attachment 411825 [details].
<rdar://problem/70477225>