Bug 217918 – Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend

• Component: New Bugs
• Status: RESOLVED FIXED

[Sam Weinig]

Tweak WebPreferences*.yaml "exposed" key to only indicate that the key should not be changeable by the frontend

[Sam Weinig]

Created attachment 411779 [details]
Patch

[Darin Adler]

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?

[Sam Weinig]

(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.

[Sam Weinig]

Created attachment 411825 [details]
Patch

[EWS]

Committed r268719: <https://trac.webkit.org/changeset/268719>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411825 [details].

[Radar WebKit Bug Importer]

<rdar://problem/70477225>