"This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl,
It's ok, sure it's stressful when something like this happens. Software is a hard field and the amount of things that can go wrong is immense. When I think about how few errors and downtime some of the larger services have I realize how much work must be involved.
I'd divide "things going wrong" into forced and unforced errors. Your upstream service providers sending subtly malformed data is a forced error. It happens. Doing user agent sniffing for presentation, poorly, is an unforced error.
It's not amateurish to have problems. It is amateurish (or malicious) to have problems caused by this specific class of issue.
What I don’t understand is why this isn’t just a rollback, or at worst a revert commit and redeploy. I can forgive an issue with a slightly obscure browser, but the fix should be trivial for Google engineers?
There's a feature important to Middle Manager 32456. You can't just revert it for a not-Google browser. That's just a no-go.
So a fix needs to be developed, QA'd, rolled. I presume it's going to be an out-of-schedule roll so it'll probably involve some bureaucracy. (One of my clients is a few thousand people public company and even there a hotfix requires QA lead approval.)
Perhaps it's been a while since it's broken? url-bar search works so this seem to only happen if you navigate to google.com directly. How many people navigate to google to search, while using firefox on android? Just a hunch though.
OTOH, it's amazing that apparently they don't have UI tests for FF mobile.
It appears that the problem is related to the version string transmitted by Firefox Mobile. If they were to send an older user agent string, the issue would likely be resolved. However, any rollback would need to be implemented by Firefox, and it seems they are not at fault here.
From Google's standpoint, this issue may be considered a "new" bug, which means they need to conduct an investigation and address it. Consequently, a rollback is not a viable solution for them.
If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
(Submitted title was "Google breaks search for Firefox users because of bad UA string sniffing")
This reminds me of a blog post a former exec of Mozilla put out saying Google had been intentionally breaking things to get users to jump ship to Chrome.
Is that what you think happened here? Google made the search page blank for Firefox users to get them on Chrome? Or perhaps it's the work of Hanlon's razor.
I don’t think there’s an official “sabotage Firefox” memo waiting to be subpoenaed. I think it’s more along the lines of Google only focusing QA on Chrome and Safari, figuring that they save money and, probably never written down, any problems just make their browser look better.
This keeps happening over and over for Google at a rate far in excess of other major tech companies so we know they don’t make an effort to test with Firefox, and it’s why I’d like regulators to force anyone making a browser used by more than, say, 100k people to be obligated to test in other browsers on every site their larger organization operates and have a maximum time to patch any compatibility or performance issue which isn’t due to a browser not implementing a W3C standard. The goal would be to cover things like YouTube using the Chrome web component API for ages after the standard shipped and serving a slow polyfill to non-Chrome browsers.
That's discussed on GP's link, a former Firefox vice president said
> "Over and over. Oops. Another accident. We'll fix it soon. We want the same things. We're on the same team. There were dozens of oopses. Hundreds maybe?"
> "I'm all for 'don't attribute to malice what can be explained by incompetence' but I don't believe Google is that incompetent. I think they were running out the clock. We lost users during every oops. And we spent effort and frustration every clock tick on that instead of improving our product. We got outfoxed for a while and by the time we started calling it what it was, a lot of damage had been done," Nightingale said.
There isn't a good reason to UA sniff. I run Firefox serving a Chrome UA as my daily driver, and never run into any issues. The reason I started this nonsense was because of a few sites that completely falsely asserted they needed Chrome to run properly, aka the only issue was the fact that they looked at the user-agent string.
Not to mention the fact that this is google.com, not some wild feat of frontend engineering. They shouldn't be serving any JS that wouldn't run on IE, forget anything close to a modern browser.
This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl and it seems that this affects all UA strings with versions >= 65. <=64 work.
It's interesting if you remove "Android" from the UA, then it sends more, but remove "Mobile" it still sends only the "doctype", and removing "Firefox" fixes it entirely.
Readit News
"This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl,
and it seems that this affects all UA strings with versions >= 65. <=64 work."Whatever UA string Firefox Mobile sends in desktop mode returned fine.
https://camo.githubusercontent.com/16a554571b3cea973d2b73464...
In IOS 14 ‘ login’ button simply does nothing regardless of the browser.
It’s been reported and yet last time I’ve checked it doesn’t work. It’s more than two months already and as it seems simply no body give a sh….
It's not amateurish to have problems. It is amateurish (or malicious) to have problems caused by this specific class of issue.
Disclosure: I work at Google but not on this. This was linked from the Bugzilla bug.
There's a feature important to Middle Manager 32456. You can't just revert it for a not-Google browser. That's just a no-go.
So a fix needs to be developed, QA'd, rolled. I presume it's going to be an out-of-schedule roll so it'll probably involve some bureaucracy. (One of my clients is a few thousand people public company and even there a hotfix requires QA lead approval.)
Nothing ever is simple.
OTOH, it's amazing that apparently they don't have UI tests for FF mobile.
From Google's standpoint, this issue may be considered a "new" bug, which means they need to conduct an investigation and address it. Consequently, a rollback is not a viable solution for them.
If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
(Submitted title was "Google breaks search for Firefox users because of bad UA string sniffing")
https://news.ycombinator.com/item?id=38349357
This keeps happening over and over for Google at a rate far in excess of other major tech companies so we know they don’t make an effort to test with Firefox, and it’s why I’d like regulators to force anyone making a browser used by more than, say, 100k people to be obligated to test in other browsers on every site their larger organization operates and have a maximum time to patch any compatibility or performance issue which isn’t due to a browser not implementing a W3C standard. The goal would be to cover things like YouTube using the Chrome web component API for ages after the standard shipped and serving a slow polyfill to non-Chrome browsers.
If it looks like a banana, shaped like a banana, feels like a banana, it’s probably a banana (or a plantain).
> "Over and over. Oops. Another accident. We'll fix it soon. We want the same things. We're on the same team. There were dozens of oopses. Hundreds maybe?"
> "I'm all for 'don't attribute to malice what can be explained by incompetence' but I don't believe Google is that incompetent. I think they were running out the clock. We lost users during every oops. And we spent effort and frustration every clock tick on that instead of improving our product. We got outfoxed for a while and by the time we started calling it what it was, a lot of damage had been done," Nightingale said.
I tend to believe him
Not to mention the fact that this is google.com, not some wild feat of frontend engineering. They shouldn't be serving any JS that wouldn't run on IE, forget anything close to a modern browser.
This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl and it seems that this affects all UA strings with versions >= 65. <=64 work.