So now `window.navigator.vendor` returns "Google Inc." if your URL matches `://app.slack.com/`. LOL.
https://github.com/mozilla/gecko-dev/blob/eea0fac2cb8cae1e5a...
Please don't browser-sniff, use feature detection instead. The web platform is standards-driven, not browser-driven -- let's keep it that way :)
This is inevitable when a browser has limited market share.
To summarize my current understanding: Slack's video conferencing service only support Chrome's non-standard Plan B format for WebRTC calls. And our attempts to talk to Slack about changing that were kindly rejected (we met with them shortly after they had launched the calling feature). And my repeated questions in public events about adding Firefox support were also turned down.
Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1626121#c4
Further clarification from last year https://bugzilla.mozilla.org/show_bug.cgi?id=1626121#c10
I have seen people mention that they have tried few more times to contact them, but Slack weren't interested.
My understanding as to why it works now, correct me if I am wrong, is because of Slack moving to using AWS Chime SDK for calls which has Firefox support and just faking the UA to Chrome tricks Slack into loads the necessary SDK/JS for calls and Chime SDK takes care of the rest.
Is there some political reason for them to disadvantage Firefox that I'm not aware of?
Firefox rolled out the standard based WebRTC implementation and chrome eventually did as well, but companies like Slack and various others didn't migrate instead just threw an error message saying calling isn't supported in Firefox and instead use their app or chrome.
Since Slack's partnership with AWS about 2 years ago, they migrated from their own call infrastructure to using AWS's Chime. Chime SDK has support for all major browsers https://docs.aws.amazon.com/chime/latest/dg/meetings-sdk.htm...
But their browser check still remains today and Mozilla started to spoof the user agent as a workaround so that Firefox users can make calls as Slack aren't willing to remove the check or properly add support.
Chrome is planning to remove WebRTC plan B soon, so this should force companies to use the unified WebRTC implementation and hopefully means Firefox support. https://groups.google.com/a/chromium.org/g/blink-dev/c/IY2am...
Just hardcode it to Chrome's once and for all.
I like Firefox, but it's the only browser to blindly follow the questionable and backwards incompatible parts of the SVG-2 spec... I challenge anyone to identify that SVG-2 <use> is implemented instead of SVG-1 <use> without parsing the useragent string.
The former is backwards incompatible (implemented in Firefox) and will render some nice black shapes if you've previously relied upon target context CSS rules for inheritance that have been supported by SVG-1 for the last decade. AFAIK you can only see this in the output since the inside of the <use> element is a shadow DOM inaccessible to JavaScript, so you cannot determine computed styles. For this reason I wrote an "unpolyfill" [0] that implements some of SVG-1 <use> elements with mutation-observers in JS, albeit in a not 100% correct way. Even so, it still needs to be explicitly enabled, depending one something else to parse the useragent string.
We enjoy far more consistency than a decade ago, but browsers are incredibly complex, and there will no doubt continue to be obscure differences that are difficult or impossible to detect programmatically. Rendering differences most of all.