Open Bug 1672445 Opened 4 years ago Updated 4 years ago

Survey Web Compatibility issues if navigator.userAgent returns 3 digit for the browser version number (User Agent, UA)

Categories

(Web Compatibility :: Tooling & Investigations, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: mhoye, Unassigned)

Details

At some point in 2021, we are going to start shipping a browser with a three digit version number. The Chrome release schedule is a lot more uneven than ours as far as I can tell - but at a glance it looks like we're going to win that race, possibly by several months.

I'm not sure where this bug belongs and what we need to do with it, but the last time we did this - from 9 to 10 - we needed to do a fair bit of outreach well ahead of time to make sure that the world didn't break when 10 shipped, so I want to make sure this is on somebody's radar.

Thanks Mike

One possible course of actions would be to do a top 1000 site screenshots comparison with and without 3 digits.
So that would give us a rough idea if there's any issue at all or if this will bite us hard. To note that many sites had fix their user agent parsing sniffing when we switch from 1 to 2 digits and in a clever way that would allow three digits. That said I can perfectly see cases where Firefox 100 will become either Firefox 10 or Firefox 00. fun! :)

How about freezing the version string at 99?

That could be an option.
But this is not the scope of this issue.
This issue is about understanding what would happen if the user agent string would reach 3 digits.

Summary: Three-digit UA numbers may ship in late 2021 → Survey Web Compatibility issues if navigator.userAgent returns 3 digit for the browser version number (User Agent, UA)

I have tested some popular UserAgent string parsing libraries using my automated testsuite I built a while ago, and to my surprise, I did not notice any new failures. The Firefox Reality UA string still causes trouble with some libraries where the Android version is returned as the browser version, but this is the case even with a two-digit version number.

The UA strings I tested with:

  • Fenix: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0
  • Firefox Desktop on Linux: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0
  • Firefox for iOS: Mozilla/5.0 (iPhone; CPU OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/123.0 Mobile/15E148 Safari/605.1.15
  • Firefox Reality: Mozilla/5.0 (Android 7.1.1; Mobile VR; rv:123.0) Gecko/123.0 Firefox/123.0

And the testsuite ran through the following libraries:

  • C#: UAParser (3.1.44)
  • Go: uap-go (latest HEAD)
  • Go: user_agent (0.5.2)
  • JavaScript: ismobilejs (1.1.1)
  • JavaScript: ua-parser-js (0.7.22)
  • JavaScript: useragent (2.3.0)
  • PHP: donatj/phpuseragentparser (1.1.0)
  • PHP: mobiledetect/mobiledetectlib (2.8.34)
  • PHP: ua-parser/uap-php (3.9.14)
  • PHP: whichbrowser/parser (2.0.42)
  • Python: ua-parser (0.10.0)
  • Python: user-agents (2.2.0)
  • Ruby: browser (5.1.0)
  • Ruby: device_detector (1.0.5)
  • Ruby: user_agent_parser (2.7.0)
  • Ruby: useragent (0.16.10)

Note that this result does not mean that we're fine - it just says that an arbitrary set of UserAgent parsing libraries (although those appear to be the most popular) return the correct values for three-digit UA strings. It's still up to the application to not accidentally treat those values as strings with two characters, do further parsing, or even invent their own UA parser, which might fail. But it's a good indication that maybe the world will not entirely be on fire.

(In reply to Dennis Schubert [:denschub] from comment #4)

I have tested some popular UserAgent string parsing libraries using my automated testsuite I built a while ago, and to my surprise, I did not notice any new failures.

Thanks for doing this.
This is quite cool.
And a very good start.

You need to log in before you can comment on or make changes to this bug.