Comment by Orphis
3 hours ago
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.
Plan-B hasn't been relevant in a very long time and Unified Plan has been in a good working shape (and used by Google Meet) for many years. Firefox has lacked many critical APIs from Unified-Plan that developer cared about for a very very long time such as everything related to simulcast and get/setParameters or codec control which are very basic and where implemented in Chromium back in 2018. Firefox didn't have them in 2024 still in working shape. So you can't really blame that long delay on Chrome or on the other APIs it shipped early.
As for the other APIs you mention, developers had wanted those shipped then, so developers got them. The risks are evaluated, but in the end, the client is king. If the standardization process is slowed down because of nitpicking and procedural mishap and not able to work with the needs of the users, it's a problem. It took years for them to be standardized while being heavily used by experts everywhere in the first version. Shipping early is also part of the standardization process where it goes to trial and it is evaluated by users, so it's not surprising to have a complex API implemented first to gather feedback. Without such feedback, none of it would have been implemented or standardized the right way. It's implementation experience that is crucial for WebRTC's domain space.
WebRTC is a live API, it's changing all the time, especially with all those expert APIs. It's not unexpected. But years long delays don't serve anyone except for late implementers that then have the newer version done and can complain that someone else is not compliant and their version is "better". No, you're just super late at implementing a live API.
That's why Firefox has been having issues with WebRTC for a long time. Having the ICE server validation WPT passing is great, but that's only an edge error case, it's not what is passed by applications in working shape or what developers need.