[popey456963]

This.

People forget that they're _actively_ appearing to break it by using this UA detection. No company should _ever_ use user-agents for feature detection, because user agents themselves are screwy in so many ways [0]. Honestly, I feel like this was someone actively deciding to break the system on Linux (or any unrecognised UA). Wouldn't any reasonable developer just send back a fully-featured page if they couldn't understand a UA?

[0] http://webaim.org/blog/user-agent-string-history/

[derefr]

UA "detection" is an unworkable mess (i.e. a bad idea) when it's trying to differentiate between different consumer web browsers. But UA detection works just fine when it's only trying to differentiate between browsers as a whole, and things that are not browsers—like web spiders, or curl(1), or your native client app.

I have a feeling that this is the latter case. The detection code was likely written to give a higher QOS priority to direct browser access, and a lower QOS priority to the native OneDrive sync service built into Windows (because it happens in the background.) But in doing so, they probably made the check ask the wrong question—"is this a browser" instead of "is this our client"—and thus wrote the check with a browser whitelist pattern (that was never tested outside of UA strings from browsers on Windows), rather than a blacklist pattern (their one sync-service UA.)

[sqeaky]

Doesn't giving web crawlers different pages than the user facing UI get you kicked out of search engine indexes? The original ticket indicated different pages were served, not just QOS.

[derefr]

(I think) we're talking about pages served to logged-in users—i.e. the pages for files and folders in a given user's OneDrive account. Web crawlers wouldn't be able to reach those either way, so it (inconveniently from a fail-early perspective) wouldn't affect anything if the detection code does something stupid/crazy in the case of crawlers.

[nathantotten]

You don't know when this code was written or what the original purpose was. User agent detection used to be a best practice. Onedrive for business is a mountain of legacy software going from sharepoint to groove to who knows what. This bug could be buried in some library that was written 5+ years ago. Maliciously going out of your way to not support Linux sounds like a good way to have your code review rejected.

[emn13]

To this day, user agent detection is the only (practical) way to avoid sending large polyfills to the 95% of clients that don't need them.

[robocat]

> No company should _ever_ use user-agents for feature detection

Wrong.

There are plenty of bugs that cannot be detected using feature detection, especially with events and <input> elements. Sometimes you can find a browser-agnostic workaround, but sometimes the only solution is to sniff the browser.

It is especially necessary if you need to support "obsolete" browsers that your customers still use.

It is important to really try and avoid browser sniffing when "fixing" bugs in current versions of browsers (since your "fix" is likely to break in future versions).

Note, feature detection usually implies that you are using JavaScript.

[greenhatman]

Yea, call my cynical, but Microsoft Office is one of the few applications that doesn't have a good alternative on Linux. So this seems like a ploy to stop people from using Linux. At least the ones that would like to use Microsoft Office.