0. With STP 183 1. Go to a website with a UA override created for webcompat reason (the list is currently in Safari, Bug 263619 will make this list public at a point). 2. check the navigator.userAgent in the console. You should get the UA which has been forced 3. Choose Develop Menu -> User Agent and change it to a different UA 4. check the navigator.userAgent in the console. Result: The User Agent has not changed. It didn't overrule the UA override from Safari. Do the same thing after disabling Site Specific Hacks, and this is working. Disabling Site Specific Hacks, in addition to disable the quirks, will also disable the UA overrides.
<rdar://problem/118981832>
Ah, I see what's happening here. In `FrameLoader::userAgent()`, after we assign the UA string to a site-specific quirk, we don't consult the `WebLocalFrameLoaderClient` for the UA string anymore. Notice the `userAgent.isEmpty()` check, which is false if we have a site-specific quirk: ``` // From FrameLoader::userAgent() if (userAgent.isEmpty()) userAgent = m_client->userAgent(url); ``` `WebLocalFrameLoaderClient::userAgent` gives us the UA string set on the web page, which happens to be either the default UA string or a custom UA string (such as the UA override from Safari's develop menu). So, it seems like we need to jiggle around our logic in `FrameLoader::userAgent()`, but I don't think we have enough fidelity to tell when we should be consulting the site-specific quirk and when we should instead be consulting `WebLocalFrameLoader::userAgent` because it will tell us a custom UA string set using the `WKPageSetCustomUserAgent` API (again, such as the UA override from Safari's develop menu).
Pull request: https://github.com/WebKit/WebKit/pull/22694
Committed 273001@main (65e9ef262a03): <https://commits.webkit.org/273001@main> Reviewed commits have been landed. Closing PR #22694 and removing active labels.