Summary: | [macOS, iOS] Expose OS marketing version in UserAgent | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> | ||||
Component: | WebCore Misc. | Assignee: | Brent Fulgham <bfulgham> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | bfulgham, cdumez, commit-queue, dbates, mitz, mjs, rniwa, sam, tonikitoo, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=200605 https://bugs.webkit.org/show_bug.cgi?id=200948 |
||||||
Bug Depends on: | 180365 | ||||||
Bug Blocks: | 192809 | ||||||
Attachments: |
|
Description
Brent Fulgham
2018-02-08 15:49:09 PST
Created attachment 333434 [details]
Patch
Having a variable user-agent string like this has been a constant source of website compatibility bugs. (In reply to mitz from comment #3) > Having a variable user-agent string like this has been a constant source of > website compatibility bugs. That's true. But there are also compelling reasons why some level of variation is needed by websites. (In reply to Brent Fulgham from comment #4) > (In reply to mitz from comment #3) > > Having a variable user-agent string like this has been a constant source of > > website compatibility bugs. > > That's true. But there are also compelling reasons why some level of > variation is needed by websites. What are those reasons? (In reply to Sam Weinig from comment #5) > (In reply to Brent Fulgham from comment #4) > > (In reply to mitz from comment #3) > > > Having a variable user-agent string like this has been a constant source of > > > website compatibility bugs. > > > > That's true. But there are also compelling reasons why some level of > > variation is needed by websites. > > What are those reasons? The primary reasons were: 1. WebKit sometimes ships with bugs that can be worked around at the website level. Having a release version allows websites to activate workarounds where needed. 2. Decisions about what site content to send to a user agent are often made before the page is loaded. Having UA information when connecting to the server allows websites to send only the relevant payload (e.g., more recent javascript, more efficient image formats, etc.) 3. Safari (for example) ships with the same version on several operating system revisions. Sometimes bugs exist in specific OS revisions that websites can work around. For these reasons, we decided to relax some of the restrictions we had originally planned on making. Comment on attachment 333434 [details]
Patch
OK.
Comment on attachment 333434 [details]
Patch
As others have already brought up, this seems like it is moving us back a step and it is unclear how valuable the OS version is for a site to work around WebKit issues given that it does not seem to provide sufficient granularity. Sites that depend on such version information will keep their WebKit workarounds longer than may be necessary.
(In reply to Daniel Bates from comment #8) > Comment on attachment 333434 [details] > Patch > > As others have already brought up, this seems like it is moving us back a > step and it is unclear how valuable the OS version is for a site to work > around WebKit issues given that it does not seem to provide sufficient > granularity. Obviously, the remark about granularity is specific to Mac where we release Safari/WebKit updates out-of-band with OS updates. On iOS, a publicly released version of WebKit always implies a new rev of the OS; => the version information is more meaningful. (In reply to Brent Fulgham from comment #6) > (In reply to Sam Weinig from comment #5) > > (In reply to Brent Fulgham from comment #4) > > > (In reply to mitz from comment #3) > > > > Having a variable user-agent string like this has been a constant source of > > > > website compatibility bugs. > > > > > > That's true. But there are also compelling reasons why some level of > > > variation is needed by websites. > > > > What are those reasons? > > The primary reasons were: > > 1. WebKit sometimes ships with bugs that can be worked around at the website > level. Having a release version allows websites to activate workarounds > where needed. Shouldn’t WebKit provide a direct and explicit way for websites to determine that a bug is fixed? > > 2. Decisions about what site content to send to a user agent are often made > before the page is loaded. Having UA information when connecting to the > server allows websites to send only the relevant payload (e.g., more recent > javascript, more efficient image formats, etc.) Aren’t there other request headers dedicated to explicitly, directly conveying what the user agent supports? > > 3. Safari (for example) ships with the same version on several operating > system revisions. Sometimes bugs exist in specific OS revisions that > websites can work around. See 1. > > For these reasons, we decided to relax some of the restrictions we had > originally planned on making. Comment on attachment 333434 [details] Patch Clearing flags on attachment: 333434 Committed r228334: <https://trac.webkit.org/changeset/228334> All reviewed patches have been landed. Closing bug. Note: For people arriving here looking for ways to live in a world with a frozen user agent, please look at <https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection> |