Preparing for Chrome 100

Chrome versions were considered quite controversial when they were first announced back in 2008. The dominant browser at the time, Internet Explorer, rarely issued major version updates, so the thought that Chrome would be updated on every new release was borderline radical. But the idea was that the end user wouldn’t need to care about each Chrome version as long as they had the latest update installed, which continues to hold true today. If you ask the average Chrome user what version they’re running, they likely couldn’t tell you. 

However, the change introduced complications for quality engineers. With every new Chrome version, there was a risk that websites could break. Almost 15 years later, there isn’t a clear solution to this problem, leaving quality teams scrambling to brace their testing strategies for potential changes. The next update, Chrome 100, launches on March 29th, posing a looming concern for quality engineers around the world. Further complicating the issue: Firefox also plans to launch their 100th version  in May. That’s great news for the average Chrome user, but what does it mean for quality engineers?

New Chrome, Who Dis?

Unfortunately, Chrome 100 is likely to give web developers, SREs, and software testers a few headaches. Many websites rely on the browser’s user-agent to detect the browser version and deliver a different experience based on the browser's capabilities. This often produced banners reading “This website works better with Google Chrome” in the past.  

The problem is that the user-agent is a mess, usually appearing as a long string of text with lots of different versions. For example, I’m writing this blog on a browser where the user-agent is “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36”. What does this actually mean? Is it Mozilla? Or is it an AppleWebKit, like Gecko? Is it Chrome 99 or Safari 537? Odds are, a website can’t tell either. 

The browser sends all these different versions to prevent being rejected by any website. If the website checks for “Mozilla/5”, it will match. The same thing will happen if it checks for “Chrome/”. Usually, developers would grab this text and attempt to find keywords to discern what browser version each device was running. This is where Chrome 100 starts posing a serious issue for web development teams. Many libraries are currently executing this action with a command like: “Look for the text ‘Chrome/’ and the next two characters will be the Chrome version.” In my case, that command will identify Chrome 99. But what happens when my user-agent is upgraded to “Chrome/100”? Instead of returning 100, that algorithm will return 10, which would be a really old Chrome version that’s not likely to be running on any device. This could revert the website to a reduced experience, disabling features reserved for “new browsers.” 

Is your website ready for Chrome 100? 

You can start preparing for these issues by testing your website. To do so manually, download Chrome 100 from the beta channel. If you have Chrome 99, it’s also possible to emulate Chrome 100 by enabling the force-major-version to 100 in the user-agent flag. This can be accomplished by copy/pasting this URL into your browser: chrome://flags/#force-major-version-to-100

Emulating Chrome 100 on the mabl test automation platform

As valuable as manual testing is, the easier path is by running local mabl tests on an emulated version of Chrome 100. The process is relatively straightforward and allows your team to test a variety of user journeys in advance of Chrome 100’s full debut next week. Let’s see how this is done.

To start, I created a simple test that navigates to an URL (this could be any test or plan in your workspace).

Now we can use the mabl CLI to run the test locally, which allows us to run this particular test against is-chrome-100-yet:

We’ll see that we aren’t running Chrome 100 yet. 

Thanks Google, I didn’t realize 99 was under 100

Luckily, we can use the new user-agent flag to create a custom user-agent and make this page think we’re using Chrome 100. The Chrome 100 user-agent will look like this: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4651.0 Safari/537.36. 

With Chrome 100 successfully mimicked on our device, we can pass the Chrome version 100 to our CLI command: 

Which will tell our software testing team if our site is ready for Chrome 100!

In this case, it’s a basic yes/no test. But as simple as it is, your organization will be able to test if your website contains any JavaScript errors that could make your test fail. By running this test in advance of Chrome 100’s general rollout on March 29th, you’re giving your team extra time to proactively mitigate any issues that will annoy customers next week. Rather than burning days reacting to issues, handling customer complaints, and potentially missing revenue, your team can rest easy knowing that your website is ready for the next generation of Chrome. 

Proactively Manage Chrome 100 Issues with Intelligent Test Automation

Managing risks to the user experience from third-party software like web browsers is a growing part of any quality engineering strategy. Modern software testing teams need tools to manage issues accidentally created by software outside your organization. As Chrome 100 approaches, mabl users (or those enrolled in our 14-day free trial) can start understanding how the new browser version will impact their website. With early warning, quality engineering teams can prepare for any potential issues created before Chrome 100 goes public on March 29th.