5 ms·

In my experience, while many people don't like to admit it, useragent detection is still one of the best ways to handle many bugs and edge cases in large applic

In my experience, while many people don't like to admit it, useragent detection is still one of the best ways to handle many bugs and edge cases in large applications. Feature detection works well for new features or well documented failures, but it quickly begins to break down in many edge cases. For example, mobile Safari shipped a broken implementation of IndexedDB for a while and detecting that was a big pain, but swapping the known bad versions to use websql or localstorage worked great. Edge (pre chromium) had some really weird bug with the JIT and the javascript `.call` function for a bit, but there was no realistic way that I could detect just that bug, so I fell back to useragent detection. There are tons of bugs that I've found over just the last few years that are due to one bad version, or some specific OS/browser/hardware combo, or are just flakey and hard to trigger with code in the page, therefore they are hard to "feature detect". I have a feeling the amount of those kinds of bugs that you see and their frequency only gets worse when you have monumentally huge amounts of traffic and users as someone like Youtube does, and while I think we should still hold them to a good standard, I can see why they would fallback to UA detection. After all, it's better to have a well working experience for most users (even with a subset of the features) than one which breaks 1% of the time (and every time it breaks, like it or not, the users are going to blame the site not the browser). What we really need (in my opinion anyway) is a way of doing UA detection that is much more scoped to specific versions, and remove the ability for those feature detections to accidentally impact new versions or other browsers (either accidentally or on purpose). Something like setting the browser name/version to a hash of the version number and a secret for each version, and possibly doing the same with other parts of the UA (like hardware/device name and OS name/version). Then people like youtube could block known broken or bad useragents from getting some features to avoid serving code that breaks to those users, and then the onus is on them to update their lists every time a new version comes out. There are obviously ways around it (UA checker as a service?), but it at least makes it harder for lazyness to take over.

saagarjha 7y ago
Could you try the faulty operation and see if it failed?
- Klathmon 7y ago
  Sometimes, but not always... For example, the Edge bug was at [1]. It didn't reproduce when the devtools were open, it only happened if the optimizer tried to optimize it which was non-deterministic, and it would only trigger in some cases in pretty weird spots with a lot of supporting code. Feature detecting that would be a nightmare, but UA detecting it (since I now know the exact versions impacted) is super easy and simple and the fix is extremely small. I don't have that in our codebase any more, but it was a perfect example of a bug which can't easily be feature-detected. [1] https://github.com/microsoft/ChakraCore/issues/1415 https://github.com/microsoft/ChakraCore/issues/1415
- penagwin 7y ago
  The problem is you can't reliability detect non-deterministic bugs, so in those cases you essentially have to use the UA to decide if you can use them.
danShumway 7y ago
To a certain extent I feel your pain and get where you're coming from. The problem is -- A) The user agent isn't always specific enough. I've run into rendering bugs that were specific not just to individual browser versions, but individual browser versions on specific platforms. I've seen bugs fixed and introduced that didn't trigger user agent updates. B) Browsers lie about their user agents. Firefox fingerprint protection normalizes the browser version reported in the user-agent to reduce the amount of information leaked. So yes, agent checks can be useful. I've used user agent checks to reduce CPU-heavy animations on older versions of IE, or target rendering bugs that literally can't be detected any other way. I get it. But when I apply those checks, I'm doing it in the spirit of progressive enhancement -- and recognizing that those checks are error prone and might fail in the future. I never gate an entire application behind a whitelist or blacklist. Bear in mind, all of the stuff you're talking about falls under the category of "I've found a bug in a weird situation and I just want to try and figure out if I'm in that situation." Not, "I've found the X situations where my site works, and it will only work in those situations." Very different approaches to web development.
- Klathmon 7y ago
  Yeah I don't support gating entire sites behind checks like this outside of some situations (like it's a tech demo using a new browser API, or a public beta where they want to limit it to a few browsers until it's stable enough to open up to the world). But I also absolutely get the allure of whitelisting "known good browsers". I've literally never seen a user hit a bug, and then blame their browser. Hell, I've personally hit bugs and blamed the website only to find out later that it was a browser bug. It's a shitty situation all around, and I don't have a good universal answer. I try to avoid doing that at all costs, but I also have to admit that a piece of software I currently work on is gated to only Chrome and Safari due to the extreme number of bugs that were coming from alternate browsers and the fact that we simply don't have the time to chase them down right now. It sucks, I feel bad about doing it, and I don't want anyone else to do it for many reasons (including the health of the web in general), but until I personally can find a good way out, I also can't in good conscience be mad at others for doing the same thing.
  - 7y ago

saagarjha 7y ago

Could you try the faulty operation and see if it failed?

Klathmon 7y ago
Sometimes, but not always... For example, the Edge bug was at [1]. It didn't reproduce when the devtools were open, it only happened if the optimizer tried to optimize it which was non-deterministic, and it would only trigger in some cases in pretty weird spots with a lot of supporting code. Feature detecting that would be a nightmare, but UA detecting it (since I now know the exact versions impacted) is super easy and simple and the fix is extremely small. I don't have that in our codebase any more, but it was a perfect example of a bug which can't easily be feature-detected. [1] https://github.com/microsoft/ChakraCore/issues/1415 https://github.com/microsoft/ChakraCore/issues/1415
penagwin 7y ago
The problem is you can't reliability detect non-deterministic bugs, so in those cases you essentially have to use the UA to decide if you can use them.

danShumway 7y ago

To a certain extent I feel your pain and get where you're coming from. The problem is -- A) The user agent isn't always specific enough. I've run into rendering bugs that were specific not just to individual browser versions, but individual browser versions on specific platforms. I've seen bugs fixed and introduced that didn't trigger user agent updates. B) Browsers lie about their user agents. Firefox fingerprint protection normalizes the browser version reported in the user-agent to reduce the amount of information leaked. So yes, agent checks can be useful. I've used user agent checks to reduce CPU-heavy animations on older versions of IE, or target rendering bugs that literally can't be detected any other way. I get it. But when I apply those checks, I'm doing it in the spirit of progressive enhancement -- and recognizing that those checks are error prone and might fail in the future. I never gate an entire application behind a whitelist or blacklist. Bear in mind, all of the stuff you're talking about falls under the category of "I've found a bug in a weird situation and I just want to try and figure out if I'm in that situation." Not, "I've found the X situations where my site works, and it will only work in those situations." Very different approaches to web development.

Klathmon 7y ago
Yeah I don't support gating entire sites behind checks like this outside of some situations (like it's a tech demo using a new browser API, or a public beta where they want to limit it to a few browsers until it's stable enough to open up to the world). But I also absolutely get the allure of whitelisting "known good browsers". I've literally never seen a user hit a bug, and then blame their browser. Hell, I've personally hit bugs and blamed the website only to find out later that it was a browser bug. It's a shitty situation all around, and I don't have a good universal answer. I try to avoid doing that at all costs, but I also have to admit that a piece of software I currently work on is gated to only Chrome and Safari due to the extreme number of bugs that were coming from alternate browsers and the fact that we simply don't have the time to chase them down right now. It sucks, I feel bad about doing it, and I don't want anyone else to do it for many reasons (including the health of the web in general), but until I personally can find a good way out, I also can't in good conscience be mad at others for doing the same thing.
- 7y ago