[482794793792894]

Yeah, but that's nonsense that bad journalists write or Mozilla marketing people say, because it's more understandable for normal readers and makes it more credible that things will change.

The truth is that they were in a dilemma situation where they had to choose between not killing all extensions or fixing performance by introducing a multiprocess architecture (which required breaking all extensions).

So, the first thing they did was to simply wait. The performance issues were not that bad yet, so it just didn't yet weigh up to kill all extensions.

Eventually they started work on the multiprocess architecture. That was around 2012, if I remember correctly. They've been doing that in the background without visible results for the public for a long time. It's considered the biggest architectural change that Firefox ever went through, so yeah, that just takes time. Cleaning up technical debt that Chrome never had.

And then they also figured, if they already break all extensions, they should also switch to a new extension API in the same breath (because the old one has had big problems for as long as its existed). So, then they implemented that, too, in the background, in parallel, just to be able to throw it all on the table one day, so that extension authors would only have to rewrite their stuff once.

[kibwen]

If this is referring to Electrolysis, that has been in stable Firefox for about a year now, and it was an initiative whose planning began in 2009. Seven years from inception to delivery is a long time, and indeed was largely attributable to trying to find ways to avoid breaking every extension in the universe, and then being forced to break every extension anyway, and then laboriously fixing up all the broken extensions over a very long period. After such a grueling task I don't blame them for coming to the painful conclusion that Firefox simply can't keep pace with other browsers while maintaining the all-pervasive legacy extension system, especially since Electrolysis was just a first tentative step towards effective multiprocessing.

Indeed, I'm one of the people who has suffered from losing legacy Firefox extensions (find me a substitute for LeechBlock, please!), but I can see how much of a burden it was for the developers to compete on performance and security, which I value more. I'm hopeful that Firefox will continue to add sane extension APIs to help close the gap with what was previously possible without regressing to the old quagmire. Fingers crossed, but they've done well delivering so far with 57.

[mook]

The first Firefox release with multiprocessing work was one of the 3.6 ones where they shipped out of process plugins in a patch release. Judging by Wikipedia, that was 3.6.4 in 2010 (look for OOPP). I thought it was later…

Having to break legacy extensions due to internal changes is understandable. It would have reduced stress for the users if the new API was shipped first, then the changes made and the old one broken, though. Heck, they even thought of it first and did that - you may remember Jetpack. It never picked up steam because the APIs were too limited and too many people ended up resorting to the old APIs, though. Even now with WebExtensions they're shipping lots of new API extensions want in the same release that drops support for the old ones…

Oh, and they had multiple breakages as more and more things went out of process, not one giant one. That's life, really; things take time to build. I believe part of the pushback is that people just finished porting to e10s only to find that their new code will need to be rewritten again for WebExtensions.

[craftyguy]

That was Mozilla's official excuse for discontinuing Firefox OS.

I never said I agreed with it.

[bigbugbag]

It seems to me waterfox has both legacy extension and multiprocess support.