Live data from Hacker News

Microsoft Teams is blocking Firefox Nightly

teams.live.com

201–210 of 316 posts

Re: Microsoft Teams is blocking Firefox Nightly

#201
post #20
post #6

Not just nightly. Stable is blocked as well. Seems we're in the next IE-era.

The posted link is to the error page. https://teams.microsoft.com works in FF stable.

Nope, it doesn't. FF stable on MacOS.

Teams is, was, and will be the absolut worst. They only won, because it's bundled into MSO.

Re: Microsoft Teams is blocking Firefox Nightly

#202

It's 2023. Why are we still doing user agent detection? We're supposed to do feature detection. userAgent is deprecated. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/u...

I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app. E.g. if you'd wanted to improve the page performance and weight of your app, you'll want to keep unused js/css to near zero. If you'd rely on feature detection, your critical path for "showing the initial screen…

Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently.

> If you'd rely on feature detection, your critical path for "showing the initial screen of the app" is bound to "download feature detect, parse it, execute it, fetch correct variants of your js/css packages, parse them, execute them, show screen". That's not cool, imho.

Even for barebones web apps, your initial html response should have either empty data (but otherwise a visible UI) or a SSR'd version of the page shown while the JS downloads and executes.

Re: Microsoft Teams is blocking Firefox Nightly

#203

I don't buy that this is accidental. When you write software, you test it on every platform you choose to support. If it doesn't work on a supported platform, then you take the time to fix it before release. It's not an "accident" when the software doesn't work on a platform you didn't bother to test on. That platform is being neglected by policy, not because of some "accident" in the code.

> When you write software, you test it on every platform you choose to support. This depends on your definition of "support". It's very likely that Microsoft do not claim to support (as in, put customer support resources behind) Firefox Nightly, this would be reasonable as it's provided for development utility, not daily use. However, I do somewhat disagree that you test it on every platform. If Teams is built as a w…

> If Teams is built as a website, do we expect them to test every feature of every release on every browser?

If they've got good unit tests, they may test every feature of every Teams release and I assume they test on all the browsers/versions that represent the vast majority of the market. They don't bother supporting FF Nightly because it's not important to them, not because of some "accident" in the code.

Re: Microsoft Teams is blocking Firefox Nightly

#204

It's 2023. Why are we still doing user agent detection? We're supposed to do feature detection. userAgent is deprecated. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/u...

There are genuine differences in browsers that need to be handled correctly and aren't easily observable or runtime-detectable. Multimedia (needed for camera/mic handling) and WebRTC still remain a giant landmine that requires UA testing 10 years later.

Web advocates can scream from the rooftops as much as they want that nobody should do UA testing, and then have basically no response when we encounter genuine browser bugs that can't be worked around.

Re: Microsoft Teams is blocking Firefox Nightly

#205

Looks like someone made a boo-boo it’s simply based on the user agent, w/e string matching they do is too strict they aren’t checking for actual JS/WebASM compatibility or anything like that. Chrome stable with a non standard user agent doesn’t work on via the windows live url but works through the O365 corporate one, same with Safari Mobile without any user agent modification. This to me looks like stupidity more th…

> Looks like someone made a boo-boo it’s simply based on the user agent, w/e string matching they do is too strict they aren’t checking for actual JS/WebASM compatibility or anything like that. Microsoft has repeatedly engaged in malicious anticompetitive behavior. Without any additional information, I therefore think it's rational to place a high prior probability on this being malicious anticompetitive behavior. Th…

Or it’s just a bug.

Re: Microsoft Teams is blocking Firefox Nightly

#206

Looks like someone made a boo-boo it’s simply based on the user agent, w/e string matching they do is too strict they aren’t checking for actual JS/WebASM compatibility or anything like that. Chrome stable with a non standard user agent doesn’t work on via the windows live url but works through the O365 corporate one, same with Safari Mobile without any user agent modification. This to me looks like stupidity more th…

it's even worse than stupidity. it's all done in the name of UX. Apple style. please use the "supported" browser.

they did the same with web Skype.

Re: Microsoft Teams is blocking Firefox Nightly

#207
post #193

Earlier quoted context omitted.

"I used to abuse people physically and/or emotionally in my early 20s but now I really hope I'm a different person" seems like a far fetched world view to conjure, to me. Do these people exist?

If you believe in incarceration as rehabilitation then they do. But I don’t recall Microsoft ever serving time.

Something life or your friends should have taught you long ago:

If you want to break cycles of abuse in your life, you need to realize and accept that you are not obligated to participate in anyone's redemption story arc but your own.

There's a whole subclass of narcissists who play at being victims while controlling everything. Get out. Run. Do not look back.

Re: Microsoft Teams is blocking Firefox Nightly

#208
post #56

My organization (which uses Teams) forcibly migrated all Firefox users to Edge a couple of weeks ago and uninstalled FF. They were citing incompatibility with some software and I assumed that meant the new ERP system being adopted by one of the larger departments.

I wonder why they don't just allow both

Re: Microsoft Teams is blocking Firefox Nightly

#209

Looks like someone made a boo-boo it’s simply based on the user agent, w/e string matching they do is too strict they aren’t checking for actual JS/WebASM compatibility or anything like that. Chrome stable with a non standard user agent doesn’t work on via the windows live url but works through the O365 corporate one, same with Safari Mobile without any user agent modification. This to me looks like stupidity more th…

>This to me looks like stupidity more than malice

Any sufficiently stupid technology is indistinguishable from malice.

Re: Microsoft Teams is blocking Firefox Nightly

#210

Earlier quoted context omitted.

I get the best practice and why relying on the User Agent is helplessly flawed, but I've never come across a better way to get a sneak peek into the (first) Initial Page Request of a customer to your web app. E.g. if you'd wanted to improve the page performance and weight of your app, you'll want to keep unused js/css to near zero. If you'd rely on feature detection, your critical path for "showing the initial screen…

Changing the UA only changes the behavior of the web server, so unless that's some block of untouchable code owned by some other team made to 'optimize' page loads for different clients, you're not doing yourself any favors by changing it in your browser; you should be loading up the client itself since you can't simulate the actual engine loading your web app differently. > If you'd rely on feature detection, your c…

1) If clients spoof their UA, they just get what they asked for. Couldn't care less.

2) With SSR you're actually making a case for sniffing the UA for the client's device class. Web apps might need to ship vastly different but overlapping code across different device classes. I'm not even talking about things that can be lazily loaded subsequently, I'm talking about the initial screen for given URL.

3) I'm _not_ going to show the customer any loading spinner or just show a white page for 2s. We had that with Java Applets, remember?

All in all, I'm not saying we should getting back into optimizing web apps for certain os/browsers/versions. What I'm saying is there might be good reasons where the mess of classifying the device on the (first) Initial Page Request is acceptable, given the alternatives.

Post reply on HN