Hacker News Reader

Comment by MBCook | Hacker News Reader

I know it would be a temporary disaster but I think at this point I wish Safari, FF, Chrome and Edge would just decide on a flag day to get rid of user agents.

From March 17th, 2023 (or whatever) all user agent strings are now “WebBrowser/1.0” until the end of time.

Just force the switch to better methods.

View on HN

I think, there's still use for it. E.g., I recall when Chrome 32 would fail to play a newly created Web Audio BufferSource, unless the playback call came from inside a decodeAudioData() callback. At the same time, you couldn't use this approach to playback sound from e.g. Safari iOS, since the callback lacked the user interaction blessing, resulting in muted audio. Try-catch wasn't an option either, since, as soon as the playback failed over any attempt to play that node in the traditional way over a null-buffer exception, the source node was already expired and won't play at all. The only way to handle this situation was user agent sniffing in order to detect Chrome and to handle it as an edge case. (Mind that the API was still the same and there was no way to feature detect this behavior.) There's no guarantee that something like this won't happen again.

That just sounds like a browser bug though. Client side code shouldn't try to work around it, the website should just notify all users that Chrome is broken and won't play audio properly

That's ridiculously naïve. You can't just decide to let your product be broken for 80% of your users because it's technically their browser that's wrong.

I see these kinds of suggestions from technologists surprisingly frequently, and I always wonder if it's a serious suggestion and if the person has ever worked on anything with non-programmers as users.

Potentially can’t notify either if you don’t have a UA string

You can notify all users until a major browser vendor fixes a known bug without a user agent.

At that time, about every audio library was broken for 80+% of the users. If you happened to maintain such a library, you received bug reports for sure (on your library). Chrome claimed their new implementation was inside specs, so it was unclear, if there would be a fix. As it happened, the specs were amended/clarified and Chrome returned to the previous behavior a few versions later.

Also this:

https://catchjs.com/Blog/SameSiteCookies

This was a huge issue for some of the software I maintain.

The link explains the problem really well.

User agent sniffing was the only option.

We have a lot of end users on older iPads that can't upgrade to a newer browser.

These users are the general public, so you can't force them to upgrade devices.

We will have to continue to do the user agent sniffing for years to come.

From the link:

> While the double cookie approach is what is recommended by Google, the ASP.NET team concluded otherwise - they found that going with a user-agent sniffing approach would be the safer approach. User-agent sniffing is hard to get right. It's hard to cover all the relevant browsers, and it's hard to do so in a way where you can be reasonably sure it won't break in user-agents of the future. But when someone gets it right, that becomes a readily copiable solution that anyone can use.

Isn't the issue here that a breaking change was introduced in a new standard version that only some browsers implement.

Why can this not be solved with http version numbers instead of a method that allows Google to maintain a seperate standard that it forces developers to switch between with user agent strings?

> The Chrome team insist that this behavior is a bug, but it is actually in line with this particular version of the spec.

Or, why any other browser is the new IE. /s

That's not possible: it assumes a perfect implementation. As I wrote in another comment: Chrome 93-95 had a weird issue with the video element. You can't test that in JavaScript. The feature exists, it just doesn't work correctly. You sometimes have to work around bugs in certain versions of certain browsers.

> Just force the switch to better methods.

I always thought software developers should have the needs of users in mind, but it turns out it's the other way around.

What if Chrome had other bug that you can't work around? Users just would have to update it. It is that simple.

Three things:

* Why do you think we can make our users upgrade? We're small, just one of dozens of websites they use per day. And in our line of business, this usually means losing clients (who, BTW, are usually not the end-users).

* How would we even be able to tell them they should upgrade if we can't test the version of their browser?

* It was Chrome 93 to 95. The bug existed for three months in all versions of Chrome. They couldn't update.

To be specific, what was the bug and what was your workaround?

Last time I had resort to UA sniffing Firefox had issues with clikable horizontal/vertical lines on SVG. There was no version that supported it properly. So I should just display "Switch to Chrome" banner for Firefox users? Is it that simple?

> There was no version that supported it properly.

So what's the point of sniffing UA? What was your fix?

They had an opportunity to do that with HTTP/2, /3, but they kept the User Agent. It's a bit different, but it's still there.

HTTP/2 is more like a transport envelope around HTTP/1, the goal of http/2 was to optimize transmission and avoid breaking http/1 semantics for servers and clients.

I think this would be a great change to do alongside http/3 or something. That way we don't break old web sites.

Permanently end the pattern of rewarding extremely bad behavior from the past. This is so simple and would work.

This would break so many websites, which would have negative consequences for many people.

what are better methods?

Just check if the thing you want is defined in JS. Maybe add some supplementary methods to help with that kind of check.

Parsing out the UA header mess is a disaster.

That don't work with render only bug, safari has tons of them. And in that case, JS is useless. Because everything reports correct, only the screen messed up.

Another example, Android webview 69 on certain devices has a bug that will take down the whole app. There is no way you can workaround it without ua sniffing. Because a single try will take the whole app away.

It can be difficult to check for bugs in this manner. Especially if the feature you want to use worked fine before, then has one or two version where it crashes, and then works again.

If you feature test for browser crashes, people are going to think it's your site, not their browser.

This is the correct answer. Allow 3rd party analytics or whatever to do as they choose, but your javascript should pretty much never believe a UA string.

`if (someFeature && someFeature.someSpecificMethod)...`

Or you can try/catch if you are less sympathetic to inferior tech.

This would be sufficient if features were a yes/no binary of supported or not, but sometimes browsers implement features but get them wrong, or incompletely.

Then the features aren't supported in the browser and you should file a bug report to the vendor. Having the developers that use a tool work around the bugs in that tool is a recipe for having millions of repeated lines of code that don't actually solve the problem upstream.

The problem being that browser vendors tend to implement Web APIs early, before the API and the respective specifications are frozen and are still likely to vary. They may even implement a certain (still valid) interpretation of the specs, which then turns out to be not exactly what everybody else eventually implements, but may stick to this for some time. (There are examples for about every browser vendor on the planet for this. Without this, if everybody had waited for finalized specs, we wouldn't have web sockets, web databases, or Web RTC for years now.) How do you handle this without version numbers?

Reply on news.ycombinator.com