[john_strinlai]

>Firefox's marketshare has plunged so far that it's getting harder to keep using it on the web

any examples? i only use firefox, including for work, as well as encourage all of my students to use it, and i cant think of any sites that dont work.

if anything, i would say its sort of the opposite (getting easier to use). some microsoft websites were wonky ~5 years ago, but now all seem to work perfectly in firefox.

[jchw]

I fairly regularly come across websites that are broken even in normal Firefox, like, even on Hacker News. I've had to use Chrome for some local government stuff but I reckon they broke Firefox on accident rather than on purpose and hopefully it is fixed now. Google's own Cloud Console was unusable in Firefox for a couple weeks a few years ago :) This is very different from sites not explicitly supporting Firefox, but it does happen. If I think of/find an explicit example of something broken right now I will link it here.

To be completely fair, some of it isn't really by choice. Like, the qmk configurator doesn't support Firefox, but that's because it needs APIs Firefox intentionally doesn't have. Should Firefox have these APIs? The WebUSB thing doesn't personally bug me the way Chrome implements it so I'd say sure. I'd certainly prefer having that over EME.

[Orphis]

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.

[sfink]

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.

[Orphis]

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.

[tekla]

Government websites tend to be an issue.

Had to spend an hour on the phone trying to figure out why my dad couldn't access a government portal. Only supported on Chrome.