7 ms·

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.

by MBCook 4y ago

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.

logicallee 4y ago
what are better methods?
- MBCook 4y ago
  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.
  - andirk 4y ago
    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.
    - Macha 4y ago
      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.
      - Xelynega 4y ago
        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.
  - masswerk 4y ago
    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?
  - toast0 4y ago
    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.
  - mmis1000 4y ago
    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.
masswerk 4y ago
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.
- Bick2 4y ago
  Also this: https://catchjs.com/Blog/SameSiteCookies https://catchjs.com/Blog/SameSiteCookies
  - masswerk 4y ago
    > 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
  - Xelynega 4y ago
    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?
  - daveoc64 4y ago
    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.
323 4y ago
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.
- oleganza 4y ago
  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.
tag2103 4y ago
Permanently end the pattern of rewarding extremely bad behavior from the past. This is so simple and would work.
deleted 4y ago
[deleted]
josephg 4y ago
I think this would be a great change to do alongside http/3 or something. That way we don't break old web sites.
deleted 4y ago
[deleted]
zagrebian 4y ago
This would break so many websites, which would have negative consequences for many people.
tgv 4y ago
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.
- ris58h 4y ago
  What if Chrome had other bug that you can't work around? Users just would have to update it. It is that simple.
  - tgv 4y ago
    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.
    - ris58h 4y ago
      To be specific, what was the bug and what was your workaround?
  - rieTohgh6 4y ago
    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?
    - ris58h 4y ago
      > There was no version that supported it properly. So what's the point of sniffing UA? What was your fix?

by MBCook 4y ago

logicallee 4y ago

what are better methods?

MBCook 4y ago
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.
- andirk 4y ago
  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.
  - Macha 4y ago
    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.
    - Xelynega 4y ago
      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.
- masswerk 4y ago
  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?
- toast0 4y ago
  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.
- mmis1000 4y ago
  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.

masswerk 4y ago

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.

Bick2 4y ago
Also this: https://catchjs.com/Blog/SameSiteCookies https://catchjs.com/Blog/SameSiteCookies
- masswerk 4y ago
  > 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
- Xelynega 4y ago
  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?
- daveoc64 4y ago
  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.

323 4y ago

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.

oleganza 4y ago
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.

tag2103 4y ago

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

deleted 4y ago

[deleted]

josephg 4y ago

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

deleted 4y ago

[deleted]

zagrebian 4y ago

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

tgv 4y ago

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.

ris58h 4y ago
What if Chrome had other bug that you can't work around? Users just would have to update it. It is that simple.
- tgv 4y ago
  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.
  - ris58h 4y ago
    To be specific, what was the bug and what was your workaround?
- rieTohgh6 4y ago
  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?
  - ris58h 4y ago
    > There was no version that supported it properly. So what's the point of sniffing UA? What was your fix?