Bug 182629 – [macOS, iOS] Expose OS marketing version in UserAgent

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Brent Fulgham]

Allow the UserAgent to expose the marketing version of the operating system WebKit is running on.

[Radar WebKit Bug Importer]

<rdar://problem/37370975>

[Brent Fulgham]

Created attachment 333434 [details]
Patch

Having a variable user-agent string like this has been a constant source of website compatibility bugs.

[Brent Fulgham]

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

[Sam Weinig]

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

[Brent Fulgham]

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

[Daniel Bates]

Comment on attachment 333434 [details]
Patch

OK.

[Daniel Bates]

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.

[Daniel Bates]

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

[WebKit Commit Bot]

Comment on attachment 333434 [details]
Patch

Clearing flags on attachment: 333434

Committed r228334: <https://trac.webkit.org/changeset/228334>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Brent Fulgham]

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>