Hacker News new | ask | show | jobs
by shadowgovt 898 days ago
If it were Chrome, it'd never have gotten out the door because the developers writing the feature use Chrome.

> if you break something in production, roll back first, ask questions about how it happened later, even if you think it's a simple fix

I don't know that they have enough information on the breakage to know when to rollback to.
1 comments
Thorrez 897 days ago
>the developers writing the feature use Chrome.

To write the code? It was only mobile Firefox that was broken. I don't think most developers write code using mobile Chrome.

link
shadowgovt 897 days ago
The UA for Desktop Chrome looks like

`Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36`

The UA for mobile Chrome looks like

`Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.210 Mobile Safari/537.36`

There is very little here different that could twig an error in the google.com UA handler.

In contrast, the Firefox Mobile one is

`Mozilla/5.0 (Android 4.4; Mobile; rv:41.0) Gecko/41.0 Firefox/41.0`

They're the only one (I can find) with "Mobile" inside the parens; bet you money the issue is a badly-formatted regex tripping over the paren / symbol combination and thinking that UA describes some deny-listed crawler somewhere (or falls off the end of recognizable UAs and trips a fallback to "Vend nothing").

Since they're always testing on Chrome Desktop, and Chrome Mobile emits an almost-identical UA string, my previous statement holds: issues with Chrome mobile are generally more likely to come up in testing on Chrome Desktop than issues in Firefox Mobile are likely to come up in testing on Chrome Desktop.

link