But things come also from Google (and Microsoft, they seem to use the same logic) implementing some logic but based on "how the web standard" works but by "how it happens to work on chrome", this leads to frequent issues with selected input devices and screen sharing.
And fixing it is easy, probably way less then 10h of work one single time. (As far as I know.)
Similar the codec issues only matter if certain slow devices are involved, e.g. non high end phones, high end phones in energy saving mode, old tablets. If no such device is involved it's not rare that the conference will anyway use different codecs. So they could support FF for many conference calls, but instead they decide to reflect to even try to work on FF (which is a web no-go btw.).
So there are "reasons", but it's clear that's they intend to not support FF at all.
Btw. Microsoft is the worst here as they reject to work with FF even for things which do not have any reason to have problems on FF.
And yet, I get flak if my code isn't performing well on 5 different browsers, including IE6.
Especially if it involves quasi monopolies.
I.e. the it's a quasi Monopoly of chrome like browsers spear headed by Google and Microsoft.
The problem is that they ram whatever internal Chrome APIs they want through standards bodies and call it a standard.
Others just can't keep up: https://web-confluence.appspot.com/#!/confluence
E: Just saw the /s in parent's grandchild.
If google devs code doesn't run as fast in firefox why should google take the blame ?
or maybe google is using non html5 apis to tap into chrome for faster perf in which case things are muddy.. since whatwg kinda allows unofficial apis