Good luck! FYI, there's a hidden developer menu that's handy for browser developers to change the number of iterations, select specific tests, etc: https://browserbench.org/Speedometer3.0/?developerMode, and ?startAutomatically avoids needing to click the button to start the tests.
I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox.
We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.
There are pros and cons to using web tech for the application UI. To be clear, the old XBL code was already using JS/DOM, so the most obvious pro in this case was that it didn't require completely rewriting Firefox from scratch (which hasn't historically worked out well). I also expect that dogfooding web technologies means we can improve the tooling and web standard implementations in Gecko.
Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.
Thanks for the info. What are you wanting to do with xpath? The console supports the $x function, like $x("//body"). Also, HTML node drag and drop is on the radar here: https://bugzilla.mozilla.org/show_bug.cgi?id=858038
Yes, the current dark theme does not have high enough contrast. There is a bug opened to switch to higher contrast colors in the dark theme here: https://bugzilla.mozilla.org/show_bug.cgi?id=971418 (and this will likely be uplifted to Aurora after landing).
Audio processing works, but certain codecs do not come bundled with it. It should be possible to configure it with --enable-libmp3lame if you had the source alongside and had everything set up correctly. We didn't have time to try this, but the closest thing I found similar to this when researching was: https://github.com/manuels/unix-toolbox.js-imagemagick. You can see that libpng, libjpeg, etc are all being included in the output.
If you'd like to give this a shot, definitely open up an issue on Github and we can talk more about the details!
Thanks! It will be interesting to see how much it will speed up as JS runtimes get faster, and as we are able to apply additional optimizations with Emscripten.
In particular, asm.js is explicitly disabled right now because of the need for memory growth. In the meantime, I'm planning on having a build with it enabled just to benchmark times on smaller files (where the growth is not needed).