As others have mentioned, while this article is about Test Pilot and focused around how you can help with UX experiments, there are lots of wonderful devs hard at work on platform features.

Some are just starting to land after literally years of work:

You might be more interested in reading about platform improvements like getting Servo/Rust components into Gecko: https://blog.servo.org/2016/05/09/twis-62/

Or progress in multi-process support (codename e10s): http://arewee10syet.com/

While these are focused on Firefox to improve performance, stability and responsiveness, there are also experiments like the Positron project, which is making Gecko able to host Electron applications: https://github.com/mozilla/positron

> As others have mentioned, while this article is about Test Pilot and focused around how you can help with UX experiments, there are lots of wonderful devs hard at work on platform features.

I don't doubt that. I just wish more resource was allocated to that, and less on new features. I do use the "share with twitter" feature, "hello" or the gtk3 integration, but I would trade it for better perf in a blink.

On the other hand, FF never saw a very disruptive feature for years. It could have added integrated torrent download or a kick ass JS/CSS IDE in browser. No perf and no disruption make is less appealing.

I'm not just complaining. I register to all the feedback program from Mozilla I encounter. I donate money to Mozilla. I activate the tracking features in my browser so they can use the metrics and crash reports.

I've been using firefox since it's been called phoenix, and it sadden me that I can't now honestly recommand it to others in any other way than "it's more ethical".

> You might be more interested in reading about platform improvements like getting Servo/Rust components into Gecko: https://blog.servo.org/2016/05/09/twis-62/

I'm dying to see servo in action. For those reasons, and also because I follow closely Rust.

The problem is that many of the slowdowns I experience in Firefox are due to existing bugs, so I'm not at all confident that adding brand new code to the browser is going to solve anything. And the rewrite isn't likely to fix slowdowns, because unless the developers figure out what is causing the performance problems, rewritten code won't magically fix it.

Oh, I forgot to mention in my sibling comment - extensions are frequently pinpointed as the cause of (or a contributing factor to) performance problems. Additionally, many of them rely on older features in the Mozilla architecture, which makes it very hard to fix without breaking extensions that people rely on.

While there has been and continues to be significant work in this area, the Web Extensions project has been making great progress and provides a much better means to contain and control extensions, while making the development experience better:

https://wiki.mozilla.org/WebExtensions/

This is already shipping today and many classic Firefox extensions have already switched over.

No, don't blame extensions. I don't run any. Here is what a modern browser is expected to handle:

Open and close tabs and windows, browsing the modern web without extensions. Keep it up for weeks, having 10 to 30 windows, and an average of 10 tabs (some at 40). You have 5 to 12 gigabytes of RAM to work with, and at least a 1920x1200 screen. (maybe a 4k screen)

That's it.

Expectations for older hardware: run for weeks, 5 to 8 windows, average of 8 tabs (one at 30), 512 megabytes of RAM, and a 1600x1080 screen.

Did you actually read and understand his comment?

> I don't run any.

You don't have to. The existence of extensions creates constraints on how they evolve the browser's internals.

Correct, supporting existing extensions constrains the architecture of Firefox.

Extensions themselves can also introduce performance problems of course.

Correct link: https://wiki.mozilla.org/WebExtensions

Oops, thanks!

While it's true that not all bugs are created equal, we do know that some bugs are exacerbated by architectural problems (single process versus multi-process is a good example of this), and new approaches like what Servo is doing in Rust make it possible to write parallel code in a way that is less likely to crash, and less likely to lead to security vulnerabilities.

In general, existing bugs (that I am aware of) are either not actionable because of existing architectural issues, or just because the nature of the bug is difficult and requires an expert whose time is constrained.