[teleproto]

One wonders why all the UI issues weren't solved long ago. Good that they're fixing them now, but what were they waiting for to decide to do it? (Rendering performance is a separate topic, that's been waiting on rust/servo.)

[internetionals]

A Large part of the reason they couldn't easily address the UI performance was because of the old extensions.

The reason that Firefox switched to webextensions was in order to switch to a formal extension API that could be supported long term, instead of the old open integration API which made it difficult to readable without breaking all sorts of extensions.

There reason they adapted the web extension API that chrome uses, was because it largely made sense, was already pretty fleshed out and would allow extension writers that were already familiar with that to also target Firefox.

[bigbugbag]

Also the fastest way to accelerate the bleeding of long time supporters and power users who would not be using firefox if not for extensions.

[WorldMaker]

My outside perspective is that as with any other major project, backwards compatibility and the momentum of old code/bugs.

I don't think they've been "waiting" to solve the UI issues: it's been years of slowly deprecating old systems like XUL, and implementing new systems like e10s. That's been years of anger or at least angst for extension developers, as much backwards compatibility was broken one piece at a time.

The fruit after all that hard work is the new UI.

[craftyguy]

One might argue because they were "distracted" with making a phone OS and other endeavors.

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

[FieryTransition]

exactly, too busy pushing resources into stuff that was not their core business while letting the competitors take their market.