Bug 182629 - [macOS, iOS] Expose OS marketing version in UserAgent
Summary: [macOS, iOS] Expose OS marketing version in UserAgent
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords: InRadar
Depends on: 180365
Blocks: 192809
  Show dependency treegraph
 
Reported: 2018-02-08 15:49 PST by Brent Fulgham
Modified: 2018-12-18 09:41 PST (History)
10 users (show)

See Also:


Attachments
Patch (1.83 KB, patch)
2018-02-08 16:25 PST, Brent Fulgham
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2018-02-08 15:49:09 PST
Allow the UserAgent to expose the marketing version of the operating system WebKit is running on.
Comment 1 Radar WebKit Bug Importer 2018-02-08 16:24:34 PST
<rdar://problem/37370975>
Comment 2 Brent Fulgham 2018-02-08 16:25:35 PST
Created attachment 333434 [details]
Patch
Comment 3 mitz 2018-02-08 16:34:28 PST
Having a variable user-agent string like this has been a constant source of website compatibility bugs.
Comment 4 Brent Fulgham 2018-02-08 17:05:13 PST
(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.
Comment 5 Sam Weinig 2018-02-08 17:08:11 PST
(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?
Comment 6 Brent Fulgham 2018-02-09 09:06:23 PST
(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 7 Daniel Bates 2018-02-09 10:44:46 PST
Comment on attachment 333434 [details]
Patch

OK.
Comment 8 Daniel Bates 2018-02-09 10:48:54 PST
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.
Comment 9 Daniel Bates 2018-02-09 10:58:34 PST
(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.
Comment 10 mitz 2018-02-09 11:04:25 PST
(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 11 WebKit Commit Bot 2018-02-09 11:19:46 PST
Comment on attachment 333434 [details]
Patch

Clearing flags on attachment: 333434

Committed r228334: <https://trac.webkit.org/changeset/228334>
Comment 12 WebKit Commit Bot 2018-02-09 11:19:47 PST
All reviewed patches have been landed.  Closing bug.
Comment 13 Brent Fulgham 2018-04-27 08:39:51 PDT
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>