[zelphirkalt]

Any ideas why it is hit and miss?

Do you test as much on FF as on Chromium based browsers, during development, as well as in quality assurance steps? I could imagine, that some devs are looking at it in Chromium (or even Chrome shudder) all day, while implementing things, and then just having to tick a checkbox for FF "Yep, seems to work.". Which would of course lead to a Chromium-centric code.

[kolAflash]

Being one of the ZetaOffice (and LibreOffice) hackers, I use Firefox as my primary browser. And I really don't like using software only Google knows how to support (=> Chromium). Sometimes I even think about migrating to SeaMonkey

But for example, you unfortunately can't properly debug multi threaded WASM code in Firefox.

https://bugzilla.mozilla.org/show_bug.cgi?id=1589908

Have a look at the Firefox developer tools' debug tab with this page opened. And it will list the threads (web workers) named with some randomized UUID. Impossible as a daily development driver :-/

https://zetaoffice.net/demo2.html

Chromium's Sources tab properly shows each thread's name. So I can easily spot "em-pthread_1" which contains the LibreOffice main thread.

But have a look at this line and you'll spot some extra code I added for running in Firefox :-)

https://github.com/allotropia/zetajs/blob/8258649a7b98fd6af9...

If you have an idea for how to fix a Firefox specific problem, please file an issue and I promise to check if we can integrate the fix.

[thorstenb]

Most devs here use FF as their daily driver - that said, if you need to debug an emscripten-compiled c++ WASM application in the browser, then it's either printf-debugging, or Chrome + the C/C++ DevTools extension. Additionally, the overall QoI for running WASM binaries appears quite a bit better for Chrome. Both issues tip the scales currently, in favour of Chrome (sadly).