A lot of websites will "work" because they added Firefox workarounds. But to a Chromium or Safari user, it might as well be called a "degraded" mode.
A lot of video-conferencing websites work that way as Firefox has had a lot of issues keeping up with the WebRTC standard evolution that power them for example.
A lot of video-conferencing websites work that way because Chrome shipped a pre-standardization form ("Plan B") of WebRTC, it got a lot of uptake, and then they refused to unship it when the final standard came out with an alternative way of doing the same thing. It took a decade to finally give in and unship the nonstandard path.
https://groups.google.com/a/chromium.org/g/blink-dev/c/IY2am...
https://webrtchacks.com/is-everyone-switching-to-unified-pla...
Then they did it again with MediaStreamTrackProcessor and MediaStreamTrackGenerator.
Then they did it again with Insertable Streams, which is still an issue for interoperable E2EE (Firefox ships a standardized variant).
If you think of websites as running on a standardized platform, then the workarounds are for Chrome, not Firefox. They include, and default to, code that calls unspecified APIs and then the ones that care autodetect when that doesn't work and fall back to APIs with actual agreed-upon specs.
Describing this as "Firefox has had a lot of issues keeping up with the WebRTC standard evolution" is... inaccurate. My impression is that there have been, and continue to be, areas where this could be leveled as a fair complaint. But refusing to implement rejected proposals because they had too much uptake already? That's the only way to keep the web platform's foundation solid.