Yes, it's an ongoing project, now in week 62. To see details of what's been fixed, and where, read this:

http://blog.mozilla.org/nnethercote/category/memshrink/

This latest fix is for misbehaving addons. Other, previous fixes, have solved a lot of problems with FF itself. For me, it's less memory hungry than Chrome.

It is unfortunate that nuance can be lost as the description of improvements moves from bugs, to technical blogs, to release notes, to the press, and finally to the reader, but I assure you that there are a number of memory-related improvements that have been made over the last year or so. These are all real, quantifiable improvements, but because modern web browsers are complex pieces of software it is not possible to fix all memory problems in a single patch.

If you look at various comparisons of browser memory usage (which are admittedly somewhat tricky to do), Firefox has, in the last 6 months or so, consistently been at or near the top of the ratings. This was not always the case, and is the result of cumulative improvement over many releases.

To the topic immediately at hand, what Firefox 15 does for memory usage is that it eliminates the single most common source of unbounded memory leaks in addons. The problem was that addons would accidentally leave behind a reference to pages, keeping them alive after they were closed, using up gobs of memory. Now, if addons try to do that, the link is killed, preventing the leak. Arguably, this is a bug in an addon and not the browser, but this has affected literally dozens of addons used by millions of people, so it called for a hardening of the browser itself to prevent this error.

Firefox never claimed to "fix the problem". The press tends to simplify things.

What is true is that multiple releases addressed separate, significant problems. It's important to remember that there is no 100% solution to a complex problem like memory usage in a large program that runs arbitrary code (the web).

Well, the fix is to have a simpler API that allows less rope for developers to hang themselves. This is how Chrome manages it. Firefox was built with this vision of XUL-based apps, big modifications, etc which never panned out. A lot of what needs to get done by extensions really can be done via simplified API like Chrome's.

A lot of the people still using Firefox instead of Chrome are sticking with FF exactly because they use extensions that can't be implemented on Chrome.

> A lot of what needs to get done by extensions really can be done via simplified API like Chrome's.

A lot of useless stuff yes, the useful stuff? Not really. Good luck building something as wide-ranging as Firebug through Chrome's API.

That's not a fix, it's a different tradeoff.

The important thing is you have choices and can pick the browser that makes the tradeoff you prefer.

Firefox has that simplified API in the Add-on SDK (aka Jetpack). However, they're stuck supporting all the traditiional XUL and XPCOM based extensions as well.

https://addons.mozilla.org/en-US/developers/tools/builder

Please demonstrate your credentials to back your claim that "done via simplified API like Chrome's". I ask because this is certainly a false statement.

Are you an extension developer? Have you ported an extension from Firefox to Chrome? Opinion is one thing; please don't misrepresent facts.

A lot, but not enough, like:

https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

Please tell me which four releases you are talking about. I'm the MemShrink project lead. It's a common misconception that we claim memory improvements all the time, but it's just not true and it drives me crazy.

If you look at the release notes, we claimed improvements in add-on memory consumption for Firefox 15, and general improvements for the browser itself in Firefox 7. (And also Firefox 3, I think, but that's ages ago predates my time working on the project.)

I know this because I wrote the accompanying blog posts for those two releases (https://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-p... and https://blog.mozilla.org/nnethercote/2011/08/09/firefox-7-is...) and liaised with marketing about the release notes.

I really want to understand where this misconception comes from. I think repeated reporting in the tech press of the same improvement as it moves from Nightly to Aurora to Beta to release might be the cause.

To be fair to them, I think this is the first that claims to fix problems specifically to do with the extensions.

I think the press (overly) publicized the add-on leak fix as it progressed through Firefox's 6-week release pipeline (Nightly -> Aurora -> Beta -> Release).

This is the case, this particular news has been reported and HN frontpaged when it came in Aurora and when it came in Beta, iirc.

That's my working theory, too. So the same improvements get reported four times, and people don't remember which channel the improvement was released on.

It has gotten better each time. Now the only things I have that leak are a few choice plugins, which I leave disabled unless I need them specifically.

If they leak from a common pattern we've identified and fixed, you should be able to enable them and no longer have leaks. If you do continue to have leaks (you can watch in about:memory) then please report them to us so we can work with the authors to correct the problem. Thanks!

This is a common misconception. You should read https://blog.mozilla.org/nnethercote/2012/08/29/debunking-a-....

(Forgive me for replying twice to your comment; this comment prompted me to go do some research and write that post.)