3 ms·

>Electrolysis apparently breaks XUL extensions. This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most

by tn123 11y ago

>Electrolysis apparently breaks XUL extensions. This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented will be enough (changes might be still wise to get away from a blocking wrapper-API to the async frame script API, but that matters only for perceived performance of the browser, not for security) DownThemAll! for example does already support e10s in the Nightly builds since quite some time, NoScript supported e10s in the past, Greasemonkey spend 9 months to add e10s support (Anthony tells in a comment to the original blog post). GM is admittedly an add-on that required a lot of changes to make it work, but it does work now apparently. https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox https://developer.mozilla.org/en-US/Add-ons/Working_with_mul...

tptacek 11y 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.
- Dylan16807 11y ago
  Extensions can, today, be asynchronous without sacrificing the more powerful model.
- makomk 11y ago
  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?
- wsha 11y ago
  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).
pcwalton 11y ago
I'll copy and paste my comment from earlier: > Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. That alone is going to break tons of addons. This necessitates a redesign. Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves.
- tn123 11y ago
  So repeating it makes it more true, eh? >Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. It is not forbidden, it is just different, using frame scripts or CPOWs. >That alone is going to break tons of addons. It will break a ton of add-ons, it will not break a ton of other add-ons. And also the "breakage" varies and would be a in the range of learning a bit about frame scripts and then fixing up a couple of tens to hundreds lines of code, as opposed to porting your entire add-on to an entirely new WebExtensions-API, which essentially would require a rewrite, if that is even possible at all without losing too much functionality. >This necessitates a redesign. It does not necessitate a redesign of the Firefox extension API if that's what you mean here. >Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Just like Add-on SDK add-ons will work in perpetuity... Oh wait, they never did. The WebExtensions API will introduce breaking changes sooner or later if you want to keep it sane and secure, as any API does, because no API is designed perfectly with perfect future vision. It will probably break far less often than the "open API", and that is a good thing. I'm not opposed at all to a nice, new, shiny, stable WebExtensions API for those users that are not affected by it's limitations. Actually, I hoped that Jetpack/the Add-on SDK would become such an API back when... >Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves. It is not friendly to intensionally break thousands of existing code bases to the point where you will need to almost completely redesign and rewrite your code, wiping out a ton of add-ons in the process because the new API is either too limited to port the code or because the author simply does not have the resources available to rewrite a ton of code.

by tn123 11y ago

tptacek 11y 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.

Dylan16807 11y ago
Extensions can, today, be asynchronous without sacrificing the more powerful model.
makomk 11y ago
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?
wsha 11y ago
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).

pcwalton 11y ago

I'll copy and paste my comment from earlier: > Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. That alone is going to break tons of addons. This necessitates a redesign. Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves.

tn123 11y ago
So repeating it makes it more true, eh? >Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox. It is not forbidden, it is just different, using frame scripts or CPOWs. >That alone is going to break tons of addons. It will break a ton of add-ons, it will not break a ton of other add-ons. And also the "breakage" varies and would be a in the range of learning a bit about frame scripts and then fixing up a couple of tens to hundreds lines of code, as opposed to porting your entire add-on to an entirely new WebExtensions-API, which essentially would require a rewrite, if that is even possible at all without losing too much functionality. >This necessitates a redesign. It does not necessitate a redesign of the Firefox extension API if that's what you mean here. >Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity. Just like Add-on SDK add-ons will work in perpetuity... Oh wait, they never did. The WebExtensions API will introduce breaking changes sooner or later if you want to keep it sane and secure, as any API does, because no API is designed perfectly with perfect future vision. It will probably break far less often than the "open API", and that is a good thing. I'm not opposed at all to a nice, new, shiny, stable WebExtensions API for those users that are not affected by it's limitations. Actually, I hoped that Jetpack/the Add-on SDK would become such an API back when... >Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves. It is not friendly to intensionally break thousands of existing code bases to the point where you will need to almost completely redesign and rewrite your code, wiping out a ton of add-ons in the process because the new API is either too limited to port the code or because the author simply does not have the resources available to rewrite a ton of code.