Yes, fail. Here’s why. All web browsers come with a User-Agent (UA). This is a string that browsers send in HTTP headers, so servers can identify the browser. JavaScript also uses it with the JavaScript navigator.userAgent. Web developers use the UA in all kinds of ways with their server-side programs. The UA’s format is: browserName/majorVersion.minorVersion As this written typical examples of the latest release versions of browsers UAs are:
Chrome: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36Firefox: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0
So, what’s the problem here? It’s an ancient one: Date format misconfigurations. The most famous example is the still not quite dead yet Y2K problem. Then, the problem was that most programs of the late 90s and earlier couldn’t deal with four-figure year dates. This time around our problem is that too many website programs can’t deal with three-figure UAs. Yes, it’s that simple. But, while it may be simple, it doesn’t mean that it’s inconsequential. You see, we’ve already had a sneak preview of this problem when we went from 1-figure UAs (1-9) to 10-figure UAs. For instance, Opera 10 wouldn’t render sites correctly back in 2009 and some sites wouldn’t render at all with Firefox 10 because their scripts read Firefox 10 as the out-of-date Firefox 1.0. We can expect all this and more as Chrome and Firefox 100 arrive. Google and Mozilla are well aware of these coming browser UA problems. Both are working on finding and fixing the headaches. Some of these problems will escape their efforts. For example, while it’s been known for decades that using UAs to determine what web pages or services should be served to a specific browser is a bad idea, that’s never stopped all too many web developers from misusing them anyway. If your website does this, odds are good your site will end up sending an error message instead of web pages to a version 100 web browsers. You can check today if your site has such a problem using a Chrome feature flag, which forces Chrome to send a three-digit UA. Then, you can check to see if the new UA is being presented properly by visiting the test site, Is Chrome 100 Yet? Then you can use this browser to check out your own sites for problems. Firefox is also offering similar tests. With either browser, if you find something breaks because of the UA before fixing it, file a report on Webcompat. Also, be sure to check that you haven’t uncovered another kind of bug by checking to see if the problem still pops up when you’re using the normal UA. In cases things go more badly than either Chrome or Firefox’s engineering teams expect, both have mitigation plans in place. In Firefox, there’s a site intervention mechanism. With this, the Mozilla webcompat team can hot-fix broken websites. To see what’s being fixed you can type about:compat in the URL bar. And, of course, if a site breaks because it can’t handle the major version being 100, a user can fix it by sending version 99 instead. But, it’s much too much to ask for ordinary users to manually change their UAs. If things go completely haywire and there are widespread site failures, Mozilla plans to temporarily freeze Firefox’s major version at 99 and test other approaches. With Chrome, the backup plan is to use a flag to freeze the major version at 99 and report the real major version number in the minor version part of the UA string. This fall-back code is already available in Chrome’s upstream open-source Chromium browser. In this case the Chrome version UA string will use the following pattern <major_version>.<minor_version>.<build_number>.<patch_number>. So, for example, the important part might look like 99.101.4988.0. Google’s Chrome developers will decide on whether to resort to this backup option if things go badly wrong. If you want to help make this problem a non-issue–the reason why people thought Y2K wasn’t that big a deal was because of all the efforts made beforehand to make sure it was properly fixed–both Google and Mozilla would welcome your help. And, of course, your own company would appreciate making sure its website doesn’t go up in smoke when the version 100 editions are released. You can do this by setting up your early release browser to report the version as 100 and report any issues you come across. Here’s how to do this. Configure Firefox Nightly to report the major version as 100
Open Firefox Nightly’s Settings menu.Search for “Firefox 100” and then check the “Firefox 100 User-Agent String” option.
Configure Chrome to report the major version as 100
Go to chrome://flags/#force-major-version-to-100Set the option to Enabled.
Before starting, keep in mind several UA string failures have already been found. If you’re a web developer using an old UA parsing library, you should test to make sure it can deal with UA versions greater than or equal to 100. Early tests show that most recent libraries will do fine. But, as we all know, the web is filled with old code. So it’s all too possible that you’re using an old, incompatible parsing library, and not even know about it until they hiccup on the latest browsers leaving your users wondering what the heck just happened. It’s time to get to work. Chrome 100 is expected to be released in March 2022 and Firefox 100 is scheduled for release on May 3. 2022. Before then, you’ll want to make sure your websites work the way you expect them to come the day, Related Stories:
How to make Google Chrome less of a battery hog on your laptopGoogle says nearly $9 million given out in 2021 vulnerability rewardsWhat about Firefox?
