[tn123]

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.

[pcwalton]

But the Add-on SDK is continuing to be supported.

And the post makes it clear that this is a long-term decision, not motivated by any one change but by the sum of all of them. The removal of the traditional status bar in Firefox 4 broke a bunch of addons. Australis had add-on compatibility implications. Electrolysis has massive add-on compatibility hazards. In the future, HTML-based UI like browser.html would have huge add-on compatibility issues, as would hardened engine components that might not support XUL/XPCOM (because it's essentially impossible to support XPCOM without being Gecko).

Nobody likes breaking addons, believe me. But I think after 10 years it's clear that the current situation needs to change, or we'll be having this conversation 2 years from now all over again, and then 2 years after that, and so on as long as Firefox is around. With one last round of deprecation we can get to a sustainable future with great addons and minimal breakage.

[simonster]

It's not entirely clear to me from the post whether the reason for changing the add-on API is to get rid of XUL/XPCOM (which was inevitable) or to limit what extensions can do for security reasons and/or to make AMO reviews easier.

If it's really just about XUL/XPCOM, there are promises you (by which I mean Mozilla) could do to make developers happier:

1) That you'll figure out what will replace XUL/XPCOM in Firefox before you force add-on developers to make similar changes. Perhaps there's been some discussion of this at Mozilla since https://mail.mozilla.org/pipermail/firefox-dev/2015-July/003... that I'm not aware of.

2) That functionality provided by non-XPCOM-based APIs currently available to extensions will remain available, e.g. OS.File and js-ctypes.

3) That there will be some mechanism for overlays for future browser UIs, beyond simple browser buttons.

If it's about limiting what extensions can do, and not about the needs of new technology, I think a serious discussion needs to happen. There's always going to be some compromise between security and liberty, and developers would probably have understood if told that they have to write things in certain ways so that the browser itself can be more secure. But telling developers that they can't build what they want to build because Mozilla doesn't trust them to write secure code is more questionable. A bad programmer can write insecure code with any extension API. (Chrome's extension API didn't protect against http://blog.kotowicz.net/2013/07/jealous-of-prism-use-amazon...) I'm hoping for an add-on API that makes it easy to do common things in a secure way, but also provides an escape hatch for people who know what they're doing.

Finally, I think developers would be happier if you finished the APIs and then gave them two years. Now we know we have 12-18 months and that Firefox will run Chrome extensions, but we have no idea what else, if anything, we'll be able to do when Mozilla flips the switch and breaks our old add-ons. We have no idea whether we should start building on top of WebExtensions, switch to an extension + companion app, or just abandon Firefox entirely.

I would much rather this conversation in 2 years when the WebExtensions API is complete, or at least complete enough that we know what to expect from it, than play a game of duck hunt while you figure out the APIs and we figure out how to tailor our extensions to them, or if we will be able to at all.