Is there a way to build Firefox without GTK? For example for something like Plasma Mobile? It would be good if there was some fallback mode where Firefox would render UI elements using HTML itself, without relying on UI toolkits.
This isn't quite a meaningful assertion. The way it works in Firefox is that a UI developer specifies in a xul or html document that there should be a button:
<button id="myButton" label="Click me!"/>
Note in particular the `-moz-appearance: button;`. This tells the rendering engine to figure out how big the button is, ask the OS to draw a button of that dimension, and then composite the OS button on top of the button node. I'm not an expert but a quick glance at the code points me to https://dxr.mozilla.org/mozilla-central/source/widget/gtk/ns..., which seems to be the main entry point for Gecko to ask for a widget to be rendered.
As you can see, Firefox does not rely on a toolkit to tell it how buttons _work_, only how they _look_. You could supply a stylesheet that overrides the -moz-appearance rules and you'll get buttons that are rendered purely by Firefox. (You might need to supply some more style rules so that they actually look like buttons.)
If you want to compile without GTK, that's a little more complicated. Firefox uses the toolkit for things like the message loop, mouse and keyboard event processing, etc. You could do all of that in straight Xlib, but who would want to? Certainly nobody has wanted to enough that they've been maintaining an Xlib port all of these years.
Since Webrender is designed like a game engine, may be it should use SDL or something of that sort.
It would be easier to simply build a Qt version of the bits that depend on GTK, so Linux users can choose between those two. But considering how little Firefox seems to care about Linux user experience (FF has been broken with transparent GTK themes since forever and nobody cares; FF removed Linux native audio support and nobody cares), I doubt this will happen and I doubt a patch would be accepted upstream for reasons of "maintenance overhead". This ignores that maintenance overhead is much higher when two independent parties have to maintain the upstream and a patchset, but is for some reason accepted practice in the open-source world.
No, they didn't. I'm listening to Soundcloud in my Firefox right now; it's sending sound to PulseAudio just fine.
What you actually meant to say is that Firefox removed support for those 1% of Linux users (i.e. 0.01% of total users) that don't have PulseAudio for whatever reason.
Well, and then you'd probably run into security restrictions, as under normal circumstances, you don't ever want something from inside Gecko to communicate with extensions and probably other things, but for this you need that capability.
Having said that, Mozilla is actually exploring into this direction: https://github.com/browserhtml/browserhtml/blob/master/READM...
And presumably, this is the future, as it would also allow them to get rid of the XUL UI Toolkit, meaning they can entirely focus on core browser technologies. (Which is something different from the XUL/XPCOM extension API that they're deprecating on Tuesday.)
That's not terribly hard to do today either. That's why browsers implemented those obnoxious fullscreen animations and notifications somewhen last year.
Browser.html is an experiment in that idea for Servo:
https://github.com/browserhtml/browserhtml
If it works out it may end up in Firefox in the long term.
Even if that means Firefox breaks every few weeks due to a new GTK release.
Even if that means Firefox never will properly support multi-monitor HiDPI on Linux (and not at all on X11).
I can see why it can be harder to bind to Qt from Rust, but this is now a solved problem I think:
https://phabricator.kde.org/source/rust-qt-binding-generator...