Bug 217918 - Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend
Summary: Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sam Weinig
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-10-19 12:44 PDT by Sam Weinig
Modified: 2020-10-20 02:28 PDT (History)
2 users (show)

See Also:


Attachments
Patch (26.29 KB, patch)
2020-10-19 12:49 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
Patch (26.29 KB, patch)
2020-10-19 19:00 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2020-10-19 12:44:56 PDT
Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend
Comment 1 Sam Weinig 2020-10-19 12:49:20 PDT
Created attachment 411779 [details]
Patch
Comment 2 Darin Adler 2020-10-19 12:56:15 PDT
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?
Comment 3 Sam Weinig 2020-10-19 13:07:38 PDT
(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.
Comment 4 Sam Weinig 2020-10-19 19:00:39 PDT
Created attachment 411825 [details]
Patch
Comment 5 EWS 2020-10-20 02:27:42 PDT
Committed r268719: <https://trac.webkit.org/changeset/268719>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411825 [details].
Comment 6 Radar WebKit Bug Importer 2020-10-20 02:28:16 PDT
<rdar://problem/70477225>