Platform Development • Re: e10s support question

I was wondering why both Pale Moon and other UXP browsers do not support e10s at all, wherever that be via a preference or enabled by defualt.

If it is on purpose, can we at least have it behind a preference (either in about:config or the browser's settings panel) for the user's convenience and the fixing of the browser "freezing"

To my knowledge, it's partly because e10s makes XUL extensions not work very well when you have multiple tabs open... they were designed around single-process browsers, and the issues with e10s were part of why Firefox ditched them for WebComponents. Job mentioned security issues, but I don't think that's the primary reason, more of a side benefit. The other issue is I believe at least some of the code they used to go e10s was implemented in Rust, which we don't want. Probably not so much of it that a half-baked e10s with a lot of issues couldn't be done, but enough that it was seen as a bad idea for our goals as a project.

I get why someone would want to try implementing e10s, though. It would help take advantage of multi-core processors more easily. Though I will say, if I wanted to do it, I would not do it the way Mozilla did it. Instead, I'd probably attempt to do it in a way that preserved XUL compatibility a bit better. Like for instance, having a root window process that uses the user's browser theme, along with any extensions that purely impact the GUI and avoid touching web content. Essentially, it would purely have the browser chrome and nothing else. Something that just sits on the desktop without having any tabs open, sort of a multi-document interface ready to go that won't parse any web content itself. Then having each tab be a new full instance of the browser, without a titlebar or controls, drawn inside a tab, with only extensions that touch web content running inside it, primarily the JavaScript parts that can manipulate web content. Essentially the trickiest part of this would be having to enforce a hard split between XUL chrome extensions that touch the browser interface, and XUL content extensions that are basically just hooks into the JS engine of a content process that modify what the user sees... and setting it up so the chrome extensions can control the content extensions in a secure manner. It's not easy, and I think that's why Mozilla gave up and killed XUL as part of their e10s migration, especially with WebComponents already existing and being popular they didn't see a need to put in the engineering work to make a multiprocess-resilient architecture for XUL. I'm sure they could have, but they didn't.

To get a preview of what this model might feel like if it could be made to work, but in a slightly inconvenient way... just launch multiple instances of your preferred UXP browser under different profiles, don't use tabbed browsing, and switch between them using the Windows Taskbar as your "tab manager" instead. You'll notice things work a lot faster, while still having XUL. That's why I think a split like that could potentially work to preserve XUL while having multiprocess, but system requirements would skyrocket, IPC would have to be handled carefully to coordinate communication between the "chrome side" and the "content side" of an XUL extension, and you would absolutely need each page to be running in a full browser process, not an e10s thing where all the different components of the browser are their own process.

But seriously, if you do want e10s as Mozilla did it to see if you think you can get XUL to work well with it, it might be easier to fork a newer version of Firefox and try to add XUL back in than to work from UXP or one of its forks... a lot of that stuff was explicitly ripped out, and wasn't really complete when we forked off anyway. At least that's my impression?