6 ms·

A lot of people here are calling for the death of UAs, but this would be bad for video because capabilities are inconsistent across the web, and because APIs ar

by vdnkh 5y ago

A lot of people here are calling for the death of UAs, but this would be bad for video because capabilities are inconsistent across the web, and because APIs are incomplete or lie. For example, the "canPlayType" API for whether a codec is supported returns "probably" or "maybe". So we sometimes need to hardcode which browsers support which new codecs. Also, there are several bugs in past and present versions of decoder implementations, which are only discovered though manual testing, or by observing quality of service metrics split by browser version (Firefox does not handle bad audio packets as well as Chrome, for example). In IE and old Edge, the video readyState would always be "4" after playback beings, even during buffering, which is a blatant violation of the spec Microsoft refused to fix (as stated in their bugtracker). Browsers like Safari have subtly different event orders from the HTMLVideoElement which requires a burdensome workaround that us working in video just like to keep to Safari instead of poisoning other implementations. A final fun quirk is that not all browsers gave accurate HTTP timing information until recently (notably, Safari < 14) which make download timing for the purpose of determining bandwidth very inaccurate. This is why Twitch only recently supported low-latency playback for Safari. There is no other way to ask "do you support accurate timing" other than for an engineer to test it and hardcode an exception.

dangerlibrary 5y ago
Counterpoint: As a user, often the only way to get a video to play in any browser on linux is to modify the user agent. And then, when you do spoof the user agent, it works just fine.
- Osiris 5y ago
  This was so common in Opera 12 that there was a dedicated button in the UI to change the user agent for a page. The browser also included a built-in user agent compatibility list and the user could manually add sites to use a specific UA string. Most sites would work fine in Opera with the correct UA. Many did not work when using the default UA with the word "Opera" in it.
  - cpeterso 5y ago
    Firefox has a built-in list of websites that need UA tweaks to work in Firefox. (In fact, Firefox's UA override feature was designed by ex-Opera engineers at Mozilla.) You can review the list (and toggle them) in Firefox's about:compat page. A recent success story: Mozilla recently added a UA tweak to work around Slack's Chrome-only check for video calls. Slack engineers reached out to Mozilla and, just a few days later, Slack removed their Chrome check and now support video calls in Firefox without a UA tweak. :)
    - heftig 5y ago
      Except if your UA reports Firefox on Linux, where calls and huddles remain unavailable to this day. I wouldn't call that a success.
      - cpeterso 5y ago
        Do the calls and huddles work in Chrome on Linux? Do they work in Firefox if you use a UA that doesn't mention Linux?
        heftig 5y ago
        Yes and yes.
        cpeterso 5y ago
        Thanks for testing. I'll ping Mozilla's web compat team about this Slack Linux problem. (I work at Mozilla.)
        cpeterso 5y ago
        I was told Slack has some Linux-specific issues that they're working on with the Firefox team, such as some complications around screen sharing depending on the window manager (as mentioned in some other comments below about Wayland vs X11).
- vdnkh 5y ago
  This is probably due to DRM which is poorly supported by Linux (lazy devs will probably just exile Linux completely). But I do remember some linux-only decoder issues in the past. Decoder and codec support is just poorly signaled overall, even if an API says it supports it, it may not support a specific profile or even support it well. Some of our video test grid machines are Ubuntu, so from our end Twitch video should work pretty well on Linux :-)
- floatboth 5y ago
  Can't say I've seen that often, but there was a short period of time when Twitch refused to play on a FreeBSD user-agent. Spoofing as Linux or Windows worked. They did fix it.
- Zardoz84 5y ago
  I really not have the need to do that. Perhaps on a few weird sites. But it's far from being the usual thing to see a video on a browser.
tjoff 5y ago
In all an insignificant price to pay. And maybe it would highlight browser vendors to fix it instead and become more standards aware.
- vdnkh 5y ago
  Getting a browser vendor to fix something takes a lot of effort, and doesn't immediately alleviate any impact on users. "if (browser.name === 'safari' && browser.version < 14)" does.
  - deleted 5y ago
    [deleted]
mixedCase 5y ago
> For example, the "canPlayType" API for whether a codec is supported returns "probably" or "maybe". Great. You should be calling for the death of UAs too if you want the situation to improve.
asddubs 5y ago
Not too long ago browser vendors decided to fuck up cookie backwards compatibility with "samesite" attribute so badly that you are literally forced to do browser sniffing to have your site work in both modern browsers and older versions of safari random article about it: https://catchjs.com/Blog/SameSiteCookies https://catchjs.com/Blog/SameSiteCookies
Uehreka 5y ago
I feel like these arguments always break down along the same lines: - People who have recently run into an issue that required browser sniffing - People who haven’t and feel sure that “things are better now” and the practice is no longer needed. I’ve gotten into these kinds of scrapes many times, and I can assure you all that philosophical arguments about browser-detection-vs-feature-detection don’t work very well when you’re trying to explain to a client why their web app that worked a week ago doesn’t work today (due to a WebRTC bug in Chrome, for instance) and won’t be fixed until the next Chrome version comes out in six weeks. To folks advocating “ripping off the bandage” as a solution, I’d note that the wound underneath has not stopped bleeding.
DaleCurtis 5y ago
FWIW, MediaCapabilities is the new way to ask the "can I play this" question: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab... It returns a boolean for whether a codec is supported or not.
danShumway 5y ago
I go back and forth. I do web development, and I do occasionally rely on the user agent, I completely agree that there are some situations where there isn't really an alternative we can use. It's not necessarily just a problem of specification, sometimes there are browser-version specific bugs that just have to be accommodated, and there is no way to test for those bugs and there is no way to get a signal for those bugs because they're not specified behavior. However, I also browse the web on Linux, and there are also situations where sites just kind of decide that they do or don't support me based on whether or not I'm in an allow-list that was lazily cobbled together and that hasn't been updated in over a year. This seems to me to be the same category of problem; it should be better, sites should know not to do that, but they don't. And sure, I can solve the problem specifically for myself by going though an annoying process to lie about my user-header, but it's a big damper on all of the other "users" (ie, random family members/friends) that I support who aren't able to do that. And it defeats the primary purpose of the user-agent if I'm lying to sites about it because they block off capabilities for no good reason from agents that they don't recognize. If I'm constantly lying about my browser as the "solution" to that problem, I'm already kind of breaking user-agents in the exact way you're worried about. And there are also obviously the privacy problems that come along with user-agents, which I'm not going to get into, but they're substantial and there is no way to solve them without making user-agents much less useful for website operators. So I don't know what the solution is, or even if there is a better solution available than what we currently have, but there are real downsides to the current setup. I think it's silly to pretend that browser vendors won't ever have quirks that make user-agents necessary. But I also think it's equally silly to pretend that website operators will ever use them responsibly, and equally silly to pretend that people won't get locked out of sites for no reason because of them. There is definitely some naivete in getting rid of user-agents, but there's also some naivete in keeping them, and the arguments for "well, they're still necessary" sometimes ignore just how much wasted effort and hacky crud goes into making the web work with them. At the same time though, there are bugs I've fixed in my day-job that could not be fixed without them. It's just, that doesn't mean the downsides aren't also there and that they don't also matter. I'm personally interested in how client hints progress. They're not perfect, but they seem to be decent, and for all of my criticism of Chrome's Privacy Sandbox concept, I think this is an area where it makes a lot of sense -- make certain hints possible to check, but have a cost associated. It's still not the exact browser version though, there are still bugs that I wouldn't be able to fix with that system. But there are some bugs that I use user-agents for that this system would work for, and I'm willing to make my job slightly harder if it makes a bunch of other things better. Or at least, I'm willing to see how client hints play out and see how much harder they do or don't make my job.
GoblinSlayer 5y ago
I spoof my UA anyway because of the sites that don't like my browser and insist on Chrome.

by vdnkh 5y ago

dangerlibrary 5y ago

Counterpoint: As a user, often the only way to get a video to play in any browser on linux is to modify the user agent. And then, when you do spoof the user agent, it works just fine.

Osiris 5y ago
This was so common in Opera 12 that there was a dedicated button in the UI to change the user agent for a page. The browser also included a built-in user agent compatibility list and the user could manually add sites to use a specific UA string. Most sites would work fine in Opera with the correct UA. Many did not work when using the default UA with the word "Opera" in it.
- cpeterso 5y ago
  Firefox has a built-in list of websites that need UA tweaks to work in Firefox. (In fact, Firefox's UA override feature was designed by ex-Opera engineers at Mozilla.) You can review the list (and toggle them) in Firefox's about:compat page. A recent success story: Mozilla recently added a UA tweak to work around Slack's Chrome-only check for video calls. Slack engineers reached out to Mozilla and, just a few days later, Slack removed their Chrome check and now support video calls in Firefox without a UA tweak. :)
  - heftig 5y ago
    Except if your UA reports Firefox on Linux, where calls and huddles remain unavailable to this day. I wouldn't call that a success.
    - cpeterso 5y ago
      Do the calls and huddles work in Chrome on Linux? Do they work in Firefox if you use a UA that doesn't mention Linux?
      - heftig 5y ago
        Yes and yes.
        cpeterso 5y ago
        Thanks for testing. I'll ping Mozilla's web compat team about this Slack Linux problem. (I work at Mozilla.)
        cpeterso 5y ago
        I was told Slack has some Linux-specific issues that they're working on with the Firefox team, such as some complications around screen sharing depending on the window manager (as mentioned in some other comments below about Wayland vs X11).
vdnkh 5y ago
This is probably due to DRM which is poorly supported by Linux (lazy devs will probably just exile Linux completely). But I do remember some linux-only decoder issues in the past. Decoder and codec support is just poorly signaled overall, even if an API says it supports it, it may not support a specific profile or even support it well. Some of our video test grid machines are Ubuntu, so from our end Twitch video should work pretty well on Linux :-)
floatboth 5y ago
Can't say I've seen that often, but there was a short period of time when Twitch refused to play on a FreeBSD user-agent. Spoofing as Linux or Windows worked. They did fix it.
Zardoz84 5y ago
I really not have the need to do that. Perhaps on a few weird sites. But it's far from being the usual thing to see a video on a browser.

tjoff 5y ago

In all an insignificant price to pay. And maybe it would highlight browser vendors to fix it instead and become more standards aware.

vdnkh 5y ago
Getting a browser vendor to fix something takes a lot of effort, and doesn't immediately alleviate any impact on users. "if (browser.name === 'safari' && browser.version < 14)" does.
- deleted 5y ago
  [deleted]

mixedCase 5y ago

> For example, the "canPlayType" API for whether a codec is supported returns "probably" or "maybe". Great. You should be calling for the death of UAs too if you want the situation to improve.

asddubs 5y ago

Not too long ago browser vendors decided to fuck up cookie backwards compatibility with "samesite" attribute so badly that you are literally forced to do browser sniffing to have your site work in both modern browsers and older versions of safari random article about it: https://catchjs.com/Blog/SameSiteCookies https://catchjs.com/Blog/SameSiteCookies

Uehreka 5y ago

I feel like these arguments always break down along the same lines: - People who have recently run into an issue that required browser sniffing - People who haven’t and feel sure that “things are better now” and the practice is no longer needed. I’ve gotten into these kinds of scrapes many times, and I can assure you all that philosophical arguments about browser-detection-vs-feature-detection don’t work very well when you’re trying to explain to a client why their web app that worked a week ago doesn’t work today (due to a WebRTC bug in Chrome, for instance) and won’t be fixed until the next Chrome version comes out in six weeks. To folks advocating “ripping off the bandage” as a solution, I’d note that the wound underneath has not stopped bleeding.

DaleCurtis 5y ago

FWIW, MediaCapabilities is the new way to ask the "can I play this" question: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab... It returns a boolean for whether a codec is supported or not.

danShumway 5y ago

I go back and forth. I do web development, and I do occasionally rely on the user agent, I completely agree that there are some situations where there isn't really an alternative we can use. It's not necessarily just a problem of specification, sometimes there are browser-version specific bugs that just have to be accommodated, and there is no way to test for those bugs and there is no way to get a signal for those bugs because they're not specified behavior. However, I also browse the web on Linux, and there are also situations where sites just kind of decide that they do or don't support me based on whether or not I'm in an allow-list that was lazily cobbled together and that hasn't been updated in over a year. This seems to me to be the same category of problem; it should be better, sites should know not to do that, but they don't. And sure, I can solve the problem specifically for myself by going though an annoying process to lie about my user-header, but it's a big damper on all of the other "users" (ie, random family members/friends) that I support who aren't able to do that. And it defeats the primary purpose of the user-agent if I'm lying to sites about it because they block off capabilities for no good reason from agents that they don't recognize. If I'm constantly lying about my browser as the "solution" to that problem, I'm already kind of breaking user-agents in the exact way you're worried about. And there are also obviously the privacy problems that come along with user-agents, which I'm not going to get into, but they're substantial and there is no way to solve them without making user-agents much less useful for website operators. So I don't know what the solution is, or even if there is a better solution available than what we currently have, but there are real downsides to the current setup. I think it's silly to pretend that browser vendors won't ever have quirks that make user-agents necessary. But I also think it's equally silly to pretend that website operators will ever use them responsibly, and equally silly to pretend that people won't get locked out of sites for no reason because of them. There is definitely some naivete in getting rid of user-agents, but there's also some naivete in keeping them, and the arguments for "well, they're still necessary" sometimes ignore just how much wasted effort and hacky crud goes into making the web work with them. At the same time though, there are bugs I've fixed in my day-job that could not be fixed without them. It's just, that doesn't mean the downsides aren't also there and that they don't also matter. I'm personally interested in how client hints progress. They're not perfect, but they seem to be decent, and for all of my criticism of Chrome's Privacy Sandbox concept, I think this is an area where it makes a lot of sense -- make certain hints possible to check, but have a cost associated. It's still not the exact browser version though, there are still bugs that I wouldn't be able to fix with that system. But there are some bugs that I use user-agents for that this system would work for, and I'm willing to make my job slightly harder if it makes a bunch of other things better. Or at least, I'm willing to see how client hints play out and see how much harder they do or don't make my job.

GoblinSlayer 5y ago

I spoof my UA anyway because of the sites that don't like my browser and insist on Chrome.