4 ms·

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 i

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.
  - tuukkah 4y ago
    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.
woojoo666 4y ago
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
- atom_arranger 4y ago
  Potentially can’t notify either if you don’t have a UA string
  - Xelynega 4y ago
    You can notify all users until a major browser vendor fixes a known bug without a user agent.
- mort96 4y ago
  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.
- masswerk 4y ago
  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.

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

woojoo666 4y ago

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

atom_arranger 4y ago
Potentially can’t notify either if you don’t have a UA string
- Xelynega 4y ago
  You can notify all users until a major browser vendor fixes a known bug without a user agent.
mort96 4y ago
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.
masswerk 4y ago
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.