| ▲ | zelphirkalt 8 months ago | |
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 8 months ago | parent | next [-] | |
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 8 months ago | parent | prev [-] | |
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). | ||