Hacker News new | ask | show | jobs
by tptacek 3955 days ago
I'm prepared to be wrong, as I am not an expert on XUL, Electrolysis, or the Firefox runtime.

I can however interpret what Mozilla says is the reasoning behind breaking XUL extensions, which is:

XUL extensions, among other things, get in the way of getting Electrolysis working.

That's linked from this blog post.

If things have to break in the short term for Mozilla to modernize Firefox's runtime hardening, well, that breakage seems worth it. Just based on the knowledge of what security flaws in Firefox get used for in the real world.

--- (few min later)

As an aside: if this is the definition of "XUL extensions can be made to work with e10s":

The lack of an synchronous API in the chrome side is intentional: because the chrome process runs the Firefox UI, any responsiveness problems affect the whole browser. By making the chrome process block on the content process, CPOWs break this principle and allow an unresponsive content process to make the whole browser unresponsive.

... I can kind of see where they're coming from, even w/o considering security.

3 comments

If this breaks stuff that users are relying on, they'll quite happily switch to Pale Moon or turn off auto-updates to get it back, and if that means they're not protected against security issues, well, I'm sure you know just how much your average user knows about security. Chances are they won't bother to switch back once the breakage is fixed either because why would they?
Electrolysis is mostly already implemented with the XUL version of Firefox and many add-ons have been ported over to be compatible with it.

The main new change being announced recently (electrolysis and extension signing have been known about for a while now) is the deprecation of XUL in the browser in general and for add-ons in particular and the adoption of a new extension API's that are more limited in functionality (WebExtensions and whatever else they decide to do to allow more functionality than is available in Chrome). There are security implications to these changes but multi-process Firefox is not the main driver. Mozilla is giving up on XUL in favor of HTML and using this as a pretext to limit the functionality of add-ons (which many Firefox developers have wanted to do for a long time for security and stability reasons).

Extensions can, today, be asynchronous without sacrificing the more powerful model.