core(emulation): emulate Chrome 100 user agent

[connorjclark]

see: https://miketaylr.com/posts/2021/09/chrome-version-100-testing.html

At worst, this updates our emulated UA string a few months early. At best, it triggers something on a webpage/server that catches a Lighthouse user's attention and allows them to prevent a production issue before it hits web users.

[brendankenny]

My first instinct is this is something we should do in the minor release after v9. This could be somewhat unexpected for users, and if it did bring up issues, I'm not sure we want to be dealing with them before the v9 release, or even if we'll be well positioned to help deal with issues brought up by this change.

m99 looks like it'll branch in mid January, so we'd still have time to try it out even before 100 is in Canary.

Maybe there's a more active approach beyond just bumping the version and seeing what shakes out? I don't have any good ideas beyond what may or may not show up in errors-in-console or just general catastrophic changes in audit results (lighthouse-ci and web.dev/measure are probably well positioned for this)

[connorjclark]

or even if we'll be well positioned to help deal with issues brought up by this change.

We won't be, but that doesn't change the fact that users will need to address it.

My first instinct is this is something we should do in the minor release after v9. This could be somewhat unexpected for users, and if it did bring up issues, I'm not sure we want to be dealing with them before the v9 release, or even if we'll be well positioned to help deal with issues brought up by this change.

"if it did bring up issues"

if there are issues, I'm hoping they get brought up. If my webserver completely falls over because of this UA change I'd want to know sooner rather than later, and AFAIK unless you're a top 1000 web partner, or happen to have seen the same tweet I did that alerted me of this problem, you won't know until Chrome 100 is stable and you are getting errors en-masse.

m99 looks like it'll branch in mid January, so we'd still have time to try it out even before 100 is in Canary.

Yeah that still gives developers who catch something problematic b/c of LH emulating 100 ~6 weeks to fix it. Well, 6w if they only use Stable chrome devtools. Perhaps more time if they observe the problem via running LH in PSI. This seems like a good enough timeframe. If we did it for the next release it'd be an additional 3 months exposure in Stable devtools, which is a more comfortable timeframe

I don't have any good ideas beyond what may or may not show up in errors-in-console or just general catastrophic changes in audit results

I'm thinking the class of errors that occur from this will range from very subtle (targeting an older browser featureset for server-side transpilation; or showing a not-supported banner) to catastrophic (the webserver returns a 500).

All that said, the safe approach is for us to do nothing, giving up our potentially unique position to alert people of this unknown risk earlier and preventing some period of broken web. If this did uncover a problem in some user's site, to the point where a LH report is no longer valid (500 response or most JS not even running), it seems like experiencing the issue in a developer tool (even though we can't detect it and quickly say "it's because of UA parsing!") would be preferable to anyone vs finding out about it first in production–so, I'd prefer a longer timeframe.

---

Perhaps a good approach would be to show a toggle in the Lighthouse panel "emulate Chrome 100 UA" with a link to a Chrome explainer :)

[adamraine]

Perhaps a good approach would be to show a toggle in the Lighthouse panel "emulate Chrome 100 UA" with a link to a Chrome explainer :)

Ya, I like this better than quietly forcing the new UA.

---

Probably overkill idea:

New UA 100 config with an extra pass/navigation and looks for new console errors and load failures with UA 100.