Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: