[GraemeLion]

But this is not a secret. This has been discussed repeatedly for at least 5 years now. The current XUL methodology CANNOT sustain, and everyone knew this.

But everyone also knew Mozilla was famous for putting off being confrontational, so nobody actually thought this was going to happen, so nobody really communicated with mozilla on what would be needed to avoid this happening. Now Mozilla has finally set a date (which maybe they won't push back YET AGAIN), and people who've not been doing work on their extensions in preparation for this, or who did not talk to Mozilla about what they need when Mozilla repeatedly asked for that information, are suddenly afraid that they're going to be left in the cold.

Mozilla does almost absolutely everything on public lists. This is all completely readable. The common thought was "they're not really ever going to do this, so we don't really need to present them with what we need, because we know they won't do this." So what else can Mozilla do? Nobody actually believed they were going to really set a cut off date. Everyone thought it'd just be pushed back over and over like it always has been.

[pseudalopex]

The problems with XUL have been discussed for over 5 years, but there hasn't been a solution. WebExtensions was announced 18 months ago, was deemed stable for developers 8 months later, and only just got a reasonable migration path with embedded WebExtensions in Firefox 51.

There's been plenty of communication from developers on Bugzilla. People are alarmed because Mozilla's original estimate fell way short, the deprecation roadmap is a lot more specific than the implementation roadmap[1], and migration is going to suck for extensions that need APIs missing from Firefox 52.

[1] https://trello.com/b/PC9kB14s/webextensions-roadmap

[alphapapa]

I don't think this is accurate. The handwriting has been on the wall for years, and I've had no doubt that Mozilla would actually rip out XUL and leave millions of loyal users hanging. Mozilla has been on an anti-existing-user trajectory for years now.

We have loudly protested. We have explained in excruciating detail how Firefox without XUL is not Firefox, and how a non-XUL Firefox will not meet our needs.

The correct response from Mozilla would have been to make XUL work with e10s, regardless of whether it's easy or fun to do so. The actual response from Mozilla has been, "Nah, that would be too hard. Besides, you don't really want XUL, because it lets in the malware bogeyman. We'll just rip it out. Don't worry, you'll thank us later."

This is heard as, "We don't care about you. We don't want your kind of users. We want those users, the ones who have switched to Chrome. You can sit on an old, outdated version until it won't load web sites anymore, and you can be constrained to the dustbin of history, where you belong."

I've no doubt there are Mozillians who do not feel that way (e.g. the Pentadactyl developers who work at Mozilla and quietly update it to work with newer versions), but that is how the message from Mozilla comes across. Most importantly, that is the net effect of Mozilla's policy.

[kuschku]

> The current XUL methodology CANNOT sustain, and everyone knew this.

Yet we still don't have a replacement for even a tenth of what it could do today!

Once Firefox 57 is released, I'll lose the ability to use Firefox at all, and won't be able to regain it for several years. Just because no one though to consider what APIs one might have to provide before deprecating the old ones.

[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.

[kuschku]

I communicated it through the bugtracker comments and the comments on the Mozilla blog.

On every announcement regarding this for the past months.

I’ve not gotten any answer, nor has any solution been implemented or suggested.

[alphapapa]

It's troubling that your comment has been downvoted.

[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.

[Kubuxu]

This addon is not worked on by paid developers.

> didn't require deep access to Firefox's internals

Quite contrary, it needs to handle new URI schema, override URL origin policy, scan pages, do DNS queries and so on.