Bug 182629

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   
Bug Depends on: 180365    
Bug Blocks: 192809    
Attachments:
Description Flags
Patch none

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>