Summary: | [iOS] Add SPI for internal clients to consult whether or not viewport quirks should be enabled | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Wenson Hsieh <wenson_hsieh> | ||||||||
Component: | Platform | Assignee: | Wenson Hsieh <wenson_hsieh> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | bdakin, hi, megan_gardner, mitz, thorton, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | WebKit Nightly Build | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Wenson Hsieh
2021-07-20 13:47:08 PDT
Created attachment 433906 [details]
Patch
Committed r280119 (239833@main): <https://commits.webkit.org/239833@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433906 [details]. Can you explain here why clients can’t use the _needsSiteSpecificQuirks property of WKPreferences? (In reply to mitz from comment #3) > Can you explain here why clients can’t use the _needsSiteSpecificQuirks > property of WKPreferences? The rationale is that this value will change out from underneath the WebKit client, so we'd want to avoid situations where a client that sets the `_needsSiteSpecificQuirks` property later reads back a different value than what it previously set. More generally, this is a hint from WebKit to the client, whereas WKPreferences is a way for clients to provide hints to WebKit. The naming collision is a bit unfortunate, though. I think that ideally, the preference would be called something like `_prefersSiteSpecificQuirks` to indicate a difference between the "hint" and "effective" value. (In reply to Wenson Hsieh from comment #4) > (In reply to mitz from comment #3) > > Can you explain here why clients can’t use the _needsSiteSpecificQuirks > > property of WKPreferences? > > The rationale is that this value will change out from underneath the WebKit > client, so we'd want to avoid situations where a client that sets the > `_needsSiteSpecificQuirks` property later reads back a different value than > what it previously set. > > More generally, this is a hint from WebKit to the client, whereas > WKPreferences is a way for clients to provide hints to WebKit. > > The naming collision is a bit unfortunate, though. I think that ideally, the > preference would be called something like `_prefersSiteSpecificQuirks` to > indicate a difference between the "hint" and "effective" value. Thank you. I think I now understand this new property’s purpose. Seems like adding “viewport” to the name would have helped with both disambiguation and clarifying the intent. (In reply to mitz from comment #5) > (In reply to Wenson Hsieh from comment #4) > > (In reply to mitz from comment #3) > > > Can you explain here why clients can’t use the _needsSiteSpecificQuirks > > > property of WKPreferences? > > > > The rationale is that this value will change out from underneath the WebKit > > client, so we'd want to avoid situations where a client that sets the > > `_needsSiteSpecificQuirks` property later reads back a different value than > > what it previously set. > > > > More generally, this is a hint from WebKit to the client, whereas > > WKPreferences is a way for clients to provide hints to WebKit. > > > > The naming collision is a bit unfortunate, though. I think that ideally, the > > preference would be called something like `_prefersSiteSpecificQuirks` to > > indicate a difference between the "hint" and "effective" value. > > Thank you. I think I now understand this new property’s purpose. Seems like > adding “viewport” to the name would have helped with both disambiguation and > clarifying the intent. The patch adopting this in the WebKit client has not landed yet, so we can (easily) fix this! Reopening to attach new patch. Created attachment 433912 [details]
Renaming
Created attachment 433913 [details]
Renaming
Comment on attachment 433913 [details]
Renaming
Thank you!
Comment on attachment 433913 [details]
Renaming
Thanks for the review!
Committed r280122 (239834@main): <https://commits.webkit.org/239834@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 433913 [details]. |