91–100 of 143 posts
Earlier quoted context omitted.
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
Potentially can’t notify either if you don’t have a UA string
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.
Earlier quoted context omitted.
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…
Also this: https://catchjs.com/Blog/SameSiteCookies
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?
Earlier quoted context omitted.
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…
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
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.
This joke flew right over me. Can someone elaborate?
Earlier quoted context omitted.
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.
Stop sending User-Agent. Replace it with nothing. Not client hints. Nothing. If sites start rejecting Firefox clients because of that, then instead change it to send exactly the same User-Agent (and other software identification) that Chrome sends, and commit to exactly faking Chrome's signals in the future. The UA header never had any business existing to begin with. Servers guessing client capabilities from the sof…
While I generally agree with you I bristtle at the "just do what chrome does" sentiment. Chrome and Google taken co trol of the standard in ways that generally aren't good for anyone.
If a website can't tell my browser apart from chrome, it can't attempt to support chrome-specitic features based on the user agent string.
Client Hints are the recommended replacement for UA strings. I believe the default behavior for Chromium browsers is already changing (looking for schedule link). [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hin...
Earlier quoted context omitted.
By default, I do not send a UA header. Mind you I use a text-only browser so I am not concerned with "responsive design", which is arguably one legit use for the UA header. The number of sites or hosting providers^1 that actually require a UA header in order to retrieve a webpage, let alone require a specific UA string, is relatively small. IME, they will fit in a short text file.^2 From firsthand experience I know t…
> so I am not concerned with "responsive design", which is arguably one legit use for the UA header. Responsive is specifically designed to work without client hints/detection, so you'd be good there anyways. Specific mobile-only versions of websites is what breaks, and a large part of that is (some?) Wordpress sites.
Earlier quoted context omitted.
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…
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