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. It will break a ton of add-ons, it will not break a ton of other add-ons. >That alone is going to break tons of addons. It is not forbidden, it is just different, using frame scripts or CPOWs. >Reaching into content windows is forbidden in multiprocess Firefox. I can kind of see where they're coming from, even w/o considering security. 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. 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. Just based on the knowledge of what security flaws in Firefox get used for in the real world.Īs an aside: if this is the definition of "XUL extensions can be made to work with e10s": If things have to break in the short term for Mozilla to modernize Firefox's runtime hardening, well, that breakage seems worth it. XUL extensions, among other things, get in the way of getting Electrolysis working.
I can however interpret what Mozilla says is the reasoning behind breaking XUL extensions, which is: I'm prepared to be wrong, as I am not an expert on XUL, Electrolysis, or the Firefox runtime. GM is admittedly an add-on that required a lot of changes to make it work, but it does work now apparently. 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)ĭownThemAll! 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). Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. It absolutely does not break XUL extensions per-se. >Electrolysis apparently breaks XUL extensions.
0 kommentar(er)
