ownedbywuigi wrote: ↑2026-04-23, 08:50
One more question (should make it a poll but you know)
Are you against
multiprocessing in general or
JUST e10s?
Considering doing a 'right' implementation of it, with just the UI being separate from the rendering, to only make the renderer freeze.
Moonchild is definitely against all of it.
For me, though, Firefox's implementation is
particularly bad even compared to say, Chrome... which I would say ironically did it first and did it better, even though I really don't like Chrome. The reason is this... Mozilla did not simply run one full browser process per tab, with all the processes ignorant of each other like a full-on virtual machine (which is the only remotely secure way to do it). That would have been very bloated and consumed a ton of resources, yes, but it might have at least been more sound than the architecture they wound up with, and I would have understood intellectually why they were doing it and thought it was a sound approach. Mozilla punched multiple holes in that sandbox and wound up trying to have their cake and eat it too, by splitting various browser components into their own processes that don't always get duplicated between tabs and reusing pieces where they could to try and regain performance, resulting in a
ton of interprocess communication going on, which means they regress back to a pre-e10s state in terms of any claimed security advantage, and still have something a lot bigger and heavier than a non-e10s browser. So they've wound up with something that's big, heavy, and very vulnerable... but feels fast most of the time.
The narrative on their end is that they did it for security. The reality if you think about it, is that they obviously chased speed and multicore performance to point of sacrificing both security and extensibility of the browser in order to make it fast and take full advantage of multicore processors with a minimum of effort. Some of the performance achievements probably could have been gained with better thread scheduling or careful multithreaded programming... they go multiprocess, the underlying OS "does it for them" so to speak, and that's probably a bigger part of it than you'd think.
The way I look at it is this... Chromium, at least back when I was watching (don't know if it's still like this now)... did their version of e10s like a virtual machine, with each tab being a bit like running a different OS in VMWare. It ate RAM like candy, yes, but it was probably the most secure and sane version of this idea. What Firefox did in the end... was not that. They didn't create a virtual machine with a full browser process for each tab, ignorant of what the others were doing. They created something more like an operating system within an operating system, and it's awful... it resembles a kernel and a lot of subsystems a lot more than it resembles any kind of virtual machine nowadays.
Like... my opinion is that e10s
could have been a lot more secure than it is now,
if that were the real goal of the people implementing it. But it's become a bit too obvious over the years that their actual goal was offloading work to the OS and chasing multicore performance with minimal effort, while making excuses to cut features and reduce maintenance burden on themselves. They are obviously content to patch security vulnerabilities as they arise, even if their architecture is fundamentally flawed, despite all their claims to the contrary.
In short... the best way to do "e10s" of some stripe, if that's what you want... is probably to just to find a way to get an embeddable version of the browser building like K-Meleon did at one point, and then look at what SubWebView did to get a Chromium instance embedded into Pale Moon. Then just take that to its logical conclusion, and create a browser that only opens tabs to run embedded versions of other browsers, and doesn't render anything itself. Then you could just turn the browser into, effectively, a kind of manager of embedded instances of itself. The downside of this, though... is that you would likely be tempted to take the "next step" and attempt to make this feel like a single browser again, by having the embedded browser instances share information or feel more seamlessly connected to the UI of their container. But if you want real sandboxing, real virtual machine architecture... you can't do that, you have to leave it in this state, let it eat a ton of RAM, and deal with it not quite feeling fully connected to the UI of what its running in. Mozilla didn't, and the result is hack upon hack and even a new programming language that tries to design itself around solving problems like this without admitting any fault in the approach itself.
When Mozilla did their e10s, they copied Chrome's homework badly and changed it a little... seriously, look at the ipc directory. It contains code from Chromium adapted to Firefox in the hackiest way possible, and then remember they piled a ton of hacks on top of that architecture that they never really understood well enough to implement it themselves in the first place. What I would say about Mozilla, is sort of like what Malcolm said in Jurassic Park about the park itself:
https://www.youtube.com/shorts/HYh-rshkBf0
To misquote him as if speaking to Mozilla, "The problem with the multiprocess/e10s power that you're using here, it didn't require any discipline to attain it. You read what Google had done and you took the next step. You didn't earn the knowledge for yourselves, so you don't take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could, and before you even knew what you had, you hacked it in, and packaged it, and slapped it on a plastic lunchbox, and now you're shipping it, you wanna ship it. Well..."
