[GraemeLion]

Partially because when Mozilla initially said "XUL is going away, what do you guys need?" Everyone just laughed at them and said "No, it's not, you'll never replace it because it is too important in extensions", and then all went away.

Where are the specs for what replaces it supposed to come from? And when they asked for those specs and got little answers, what were they supposed to do? Run around screaming "No we're serious this time, we really are going to drop this, and we really need you guys to work on getting requirements voiced? And also it'd be great if you took us seriously about e10s too!"

One of my favorite extensions is vimperator. There are comments going back over a YEAR that there would be problems with e10s and XUL, and they were always just pushed off and ignored because it wasn't a current situation. I've got two or three other extensions whose github issues section mirrors the same situation. Some of them thought Mozilla would put in a "allow me to run dangerous addons" button and leave the code in play, but if add on developers can do that, then malicious add on developers can too.

[alphapapa]

This call for, "Just tell us what APIs you need!" is missing the point.

1. There's no guarantee that Mozilla will actually implement such APIs, and no guarantee that they will actually support them in the future. If past behavior indicates future behavior, they will support them for 12-18 months and then say, "It's not worth the effort anymore. But here's a new bundled Facebook plugin that we're totally not being paid to put in. Have fun!"

2. More importantly, many of these extensions would never have come to exist if their authors had had to beg Mozilla to implement an API first. If XUL had never existed, would ad-blocking extensions have ever been created? I can imagine the Bugzilla pages now: "This is not a priority for our limited manpower. Restricting this issue due to advocacy. You can discuss it further on the mailing list."

Firefox - XUL != Firefox

[kuschku]

For me, I have requested the same since the beginning — just allow me to modify the UI with a markup language.

Or I'll fork, merge all upstream patches down, and work with that.

Currently I have to rely on the AutoHiDPI addon because firefox is otherwise unusable on my system (linux with two screens with very different DPIs).

I also asked for a way to get tab thumbnails done, and to replace the entire bookmark and omnibar system.

But no. Now I'll have to fork Firefox to get a usable browser.

[GraemeLion]

Did you request this with your plugin/addon developers, or with mozilla yourself through their many methods of contact for this if you are a plugin/addon developer?

I don't get why addon/plugin developers not communicating upstream is the problem of upstream.

[Kubuxu]

Yup, this is one of the developers that took it serious [0]. You can see, he started preparing in August of 2015. If other developers did that, this info wouldn't be a problem.

[0]: https://github.com/lidel/ipfs-firefox-addon/issues/20

[trome]

IPFS is a one off though, it has multiple paid developers who can spend their full time rewriting their addons at the drop of a hat. Plus that IPFS addon didn't require deep access to Firefox's internals, which many popular addons do.