add-ons Firefox Memory consumption MemShrink

Firefox 15 plugs the add-on leaks


Firefox 15 prevents most memory leaks caused by add-ons, including Firebug.  For many users with add-ons installed this will significantly reduce Firefox’s memory consumption, without requiring upgrades to those add-ons.

For those users, Firefox 15 is likely to be faster (sometimes drastically so) and less likely to crash, especially if they have multiple add-ons installed and/or keep Firefox running for a long time between restarts.

The Problem

A memory leak occurs when a program allocates some memory but then fails to free it.  There are multiple causes of memory leaks, but they all have the same effect:  an increase in memory consumption, which often grows as the program runs. This can cause poor performance, and even lead to crashes or aborts due to the exhaustion of available memory.

Many Add-ons Leak

I’ve lost count of the number of times I’ve seen (and participated in) variants of the following conversation during the past year.

Alice: Firefox is slow and using 2GB of memory.  WTF?
Bob:   Do you have any add-ons installed?
Alice: Yes.  Why?
Bob:   Try disabling them all and restart Firefox.
Alice: Ok... Oh wow.  That's much better.
Bob:   Now you have to disable them one at a time to work
       out which one(s) are at fault.
Alice: Really?  Hmm, that sucks.
Bob:   Yeah.  Sorry about that.

Although Firefox itself isn’t immune to memory consumption problems, Mozilla’s MemShrink project has fixed enough problems in Firefox itself that in January of this year I declared that the #1 way to improve memory consumption in Firefox would be with “Better Detection and Notification of Leaky Add-ons“.

I said this because many add-ons have memory leaks.

Happily, most of the leaks in the mentioned add-ons have been fixed by their developers.  But by now it should be clear that (a) memory leaks are common, and (b) no add-ons are immune, no matter how simple they are, or how good their developers are.

The other thing to note is that these add-ons each exhibited a particular kind of leak that we call a zombie compartment.  The gory details of zombie compartments are beyond the scope of this blog post;  the important thing is that they are common, accounting for 90% or more of the add-on leaks we’ve seen.

Leaky Add-ons Make Firefox Slow and Crashy

So, leaky add-ons are common.  What effect do they have?

Not all leaks are created equal.  Some add-ons leak a small amount of memory; some add-ons leak an unbounded amount of memory.  Users with multiple add-ons are more likely to suffer problems. Certain browsing patterns may exacerbate leaks.  Overall, it’s very hard to characterize.

Nonetheless, affected users may experience high memory consumption, which has the following visible effects.

  • Long freezes, caused by garbage collection and cycle collection.
  • General sluggishness during basic operations, like scrolling and switching tabs.
  • Occasional drastic slowdowns — particularly on machines with small amounts of RAM such as netbooks — due to the paging of data to and from the hard disk.
  • Out-of-memory crashes or aborts, particularly on Windows and ARM machines.

For example, one user who disabled a leaky version of 1Password experienced a much leaner and faster Firefox as a result.

I only use a handful of extensions and honestly never suspected 1P, however after disabling it I noticed my FireFox performance increased very noticibly. I’ve been running for 48 hours now without the 1P extension in Firefox and wow what a difference. Browsing is faster, switching is faster, memory usage is way down.

(My emphasis.)

We’ve heard this kind of story many times, and this one is typical because the user never suspected that an add-on was the cause of the problem.  Leaks in add-ons are not Mozilla’s fault, but they are Mozilla’s problem — Firefox gets blamed for the sins of its add-ons.  This isn’t surprising, because Firefox hasn’t provided tools that would let users understand when add-ons are causing problems.

What has Mozilla done about this before now?

For a long time, we lacked memory profiling tools that were (a) powerful enough to detect add-on leaks, and (b) simple enough to be used by users who weren’t also Firefox developers.  This meant that we didn’t appreciate how many problems were caused by leaky add-ons.

That changed last year.  The infrastructure with which we detect zombie compartments was implemented in two parts:  the segmentation of the JavaScript heap into compartments (which happened in Firefox 4, released in March 2011), and the addition of per-compartment memory reporting in Firefox’s about:memory page (which was added in Firefox 7, released in September 2011).

Once these tools were in place, the reports of leaky add-ons started rolling in, and it only took a few months to realize the magnitude of the problems they were causing.  We started tracking them, we helped authors fix them, and tightened the AMO review guidelines so that any add-on that was found to cause zombie compartments would have its status downgraded.

As a result, dozens of leaky add-ons were fixed.  But there are literally thousands of Firefox add-ons in existence, many of which aren’t hosted on AMO and so aren’t subject to the AMO review policies.  And although many add-on authors were responsive, some weren’t.  It was a tedious game of whack-a-mole, and something better was needed.

The Fix

Leaky add-ons usually cause zombie compartments by holding references to DOM structures within a web page even after the page has been closed or navigated away from.  This prevents Firefox from garbage-collecting the page’s compartment.

Mozilla engineer Kyle Huey had the radical idea of simply detecting these kinds of references and cutting them.  This would eradicate this entire class of memory leaks for good, without requiring any changes to individual add-ons.

However, it wasn’t at all obvious that this would work.  In particular, it was possible that code within Firefox and/or add-ons might be broken by this change.  But it turned out, once some bumps were cleared, that almost no code was broken and the leaks were prevented exactly as predicted.  This fix is present in Firefox 15.

Confirmation via in-house testing

I did some early testing on a number of add-ons that were known to leak:  Firebug 1.9.1, McAfee SiteAdvisor 3.4.1, PicPasso 1.0.1, LoL 1.5, YouTube Ratings Preview 1.03, Enter Selects 7, HttpFox 0.8.10, and Link Resolve 0.7.  In every case, Firefox 15 prevents the leaks.

We’ve subsequently confirmed that a number of other leaking add-ons have been fixed by this change.  Although add-ons can still cause zombie compartments in obscure cases, we are yet to encounter such a case in practice.

Confirmation from real-world users

Firefox users can enable telemetry, which is a feature that periodically sends anonymous performance-related data to Mozilla.  This allows us to analyze how people use Firefox in the real world.

We don’t track zombie compartments via telemetry, but we do track something called ghost windows.  The gory details of ghost windows are also beyond the scope of this blog post;  the important thing to know is that they correlate strongly with zombie compartments — a high ghost window count very likely indicates the presence of zombie compartment, and thus memory leaks.

The following graph shows the ghost windows telemetry measurements for users of Firefox Nightly builds on Windows during April and May 2012.  The line marked with a 1 shows when Kyle’s patch landed, and the lines marked with 2 and 3 show when some related follow-up patches landed.

Ghost Windows telemetry results

Telemetry data tends to be very noisy, and this graph is no exception, but the effect is clear.  The mean number of ghost windows (shown by the blue dots) dropped from typically between three and four to typically less than one.  (As for why it’s not zero, one reason is that ghost windows can be false positives — i.e. they don’t always correspond to actual leaks.)  Furthermore, the variance has dropped greatly.  Previously, the hardest-hit 5% of measurements would typically have at least 15 or 20 ghost windows, and the next hardest-hit 20% would typically have at least two.  After the fix, the hardest-hit 5% of measurements typically have only two or more ghost windows, and the remaining 95% typically have zero.  This graph is a few weeks old now, but the measurements for Firefox 15 since then have remained steady.

In other words, ghost windows have changed from something that many users experience to something that few users experience.  Furthermore, those users who are still affected experience many fewer than before.  This graph also provides further evidence that add-ons are responsible for a large fraction of the memory leaks encountered by Firefox users.

The Benefits of the Fix

Our testing

I compared pre-release versions of Firefox 14 and Firefox 15 with McAfee SiteAdvisor 3.4.1 installed.  SiteAdvisor is a very popular add-on that rates the safety of web sites, and version 3.4.1 had an unbounded memory leak that leaked significant amounts of memory on every page that Firefox visited.  (That leak has since been fixed and version 3.4.1 is no longer available from McAfee.)

I did the testing on a fast desktop machine with Windows 7 installed.  I ran MemBench, which is a memory test benchmark that opens 150 popular websites, one per tab, and then closes them all.  This test is a reasonable facsimile of several hours of web browsing.

I used about:memory to measure memory consumption (a) with the 150 tabs open (plus one more tab for about:memory itself), and then (b) after closing those 150 tabs.  The metric I measured was resident memory consumption, which is the amount of physical memory used by Firefox.  It is measured by the operating system.  Firefox 14’s two measurements are on the left, and Firefox 15’s two measurements are on the right.

Resident Memory Consumption (MB) on MemBench of Firefox 14 & 15 with SiteAdvisor 3.4.1 add-on

The graph tells a clear story.  The leak in SiteAdvisor 3.4.1 prevents Firefox 14 from releasing most of the memory used by the 150 MemBench tabs, even after those tabs are closed.  In contrast, Firefox 15 prevents the leak.  As a result, after closing 150 tabs, Firefox 15’s resident memory consumption is 4.8x smaller than Firefox 14’s (compare the red bars) without any change to the add-on.

Feedback from users

The feedback from users of the pre-release Nightly and Aurora versions of Firefox has been overwhelmingly positive.  Here are some notable examples.

One user experienced a 4x reduction in memory consumption at the end of the day.

I seem to be seeing really significant improvements from this. Normally Fx would start at 170MB and by the end of the day that would often be creeping up to 800 or 900 MB. Today using latest nightly I again started at 170, but now at the end of the day I’m only at 230MB!

I knew that my addons were the culprit, yet the list I have at the moment is a tenured list of addons I wish to keep. This fix allows me to continue being an addon junkie without the pernicious side effects. Thank you so much!

Another user reported via email that a 1.5GB per hour leak — which caused 10+ second pauses and necessitated frequent restarts — disappeared.

Firefox was leaking about 1.5GB per hour for me. It started with Firefox 3. I tracked it down to Ghostery and NoScript, but even without those addons it leaked about 500MB per hour of browsing.

GC and CC times got up into the 10 second range. Ugly. Really really ugly! And this is on top of the line massively overclocked hardware, too. I had to install a new addon to add a restart button to Firefox, because Firefox froze solid after hitting 2GB of memory usage…

Then your patch comes along and solves it all… totally awesome!

Another user experienced faster painting, scrolling, and input operations.

Certainly, before this fix I would find that Firefox often became sluggish (input lag, slow paint operations, less than silky smooth scroll animations) as the memory usage built up… I haven’t noticed the same symptoms since… the signs certainly seem to be good.

These quotes nicely highlight the potential benefits:  greatly reduced memory consumption, which leads to fewer pauses, faster overall performance, and no need to restart Firefox to restore optimum performance.


Based on the evidence above, we are confident that Firefox 15 fixes the vast majority of add-on memory leaks, and that as a result, many users will see drastic improvements in Firefox’s performance and stability.  However, predicting the exact effects of this fix on the hundreds of millions of Firefox users is essentially impossible, due to the huge number of different add-ons that are available, and the great variety of add-on and browsing usage patterns.

Nonetheless, if you are a heavy add-on user and you have noticed Firefox’s performance degrade during long browsing sessions, there is a good chance you will see large improvements.  Firebug users may notice improvements as well.  But, as they say:  your mileage may vary.


Over the past year, Mozilla has made great progress in reducing Firefox’s memory consumption.  However, the excessive memory consumption caused by add-ons with memory leaks has remained an ongoing problem.

Firefox 15 fixes that problem.  We have confirmed, via in-house testing and from real-world telemetry data, that it prevents the vast majority of leaks that occur in existing add-ons.

Users who upgrade to Firefox 15 won’t have to upgrade their add-ons to see the benefits.  While it is hard to predict the effect of this improvement on any individual user, many users should experience greatly reduced memory consumption, particularly on long browsing sessions.  This should result in better performance, fewer pauses, and fewer crashes.

Mozilla’s MemShrink efforts are ongoing.  We have various projects in the pipeline that aim to further reduce Firefox’s memory consumption, and help users understand better how Firefox is using memory.  Hopefully these changes will make it into Firefox releases not far from now!

96 replies on “Firefox 15 plugs the add-on leaks”

I’m having issues with Firefox 15, but I guess is fault of Ghostery, HTTPS Everywhere, LastPass, Google Search By Image or Feedly. Saddly, I couldn’t find the real problem yet.

Can you be more specific by what you mean by “issues”?

I used to use Ghostery about 3 months ago but found it very sluggish and bad on resources – I now use Fanboys ultimate list for ABP which blocks all trackers better then Ghostery did with much better performance.

HTTPSeverywhere, the only issue I had was a Dev build which leaked a ton of RAM, I have no issues with it’s RAM usage anymore.

The other 3 addons I have no idea about – try running in safe mode with addons disabled and see if it is better?

What about memory leaks by add-ons on the ESR version? We have an enterprise level deployment of Firefox 10 ESR and we are seeing a huge increase in RAM usage while browsing our webapp. Firebug is the only add-on we use although I’m not sure that is installed on all systems.

Is the ESR version affected by the memory leak too? Will there be an update for it?

This change won’t go into the current ESR 10 release. However, it will be present in the ESR 17 release which is due for release on November 20.

One would hope that telemetry data collectors will be present through out Firefox overtime. That way Mozilla can detect regressions and problems better in future. The fact that you have users having to leave in masses to realise their is a problem in you product is not exactly ideal…

It is one of the great things about IE9 and IE10. It might not be cutting edge, but one just get the feeling that it is properly engineered.

As someone who has to develop with IE as a target browser, let me just tell ya, I really needed the chuckle that last sentence gave me. I know you probably didn’t mean it as a joke, but I took it as one and it brightened my day.

I use Ghostery and Adblock Plus and haven’t found any slowdowns or extra memory usage.
(When can we comment here with a browser ID?)

Firefox 15 beta 1 on Windows 8 64bit not closed. Plugin flash block firefox shut down. I downgrade to Firefox 14.0.1 and it’s work. Check this bug please!

One of the sites I use frequently, implements polling for updates not with XHR, but uses an iframe with meta refresh every few seconds. Firebug (at least version 1.9 — have not tried with 1.10 yet) attaches itself to the DOM of each document as it is loaded into the iframe and it never gets released until the browser is restarted. Having this site open for any length of time cumulative in a session basically kills performance for that session, memory use explodes and brings my system to near constant full CPU-core use doing nothing but GC every few seconds. As a web developer, uninstalling Firebug is not an option. I’ve had to have Chrome (which I don’t particularly like) running alongside Fx (my primary browser) just for this one site which I’d much prefer to have pinned in Fx.

Ever since I read about this effort, I can hardly wait for Fx15 to fix this.

Version 15 is in beta but the builds in the beta channel haven’t updated from 14 yet (they will soon).
I’ve been running 15 in the aurora channel and it’s stable.
So if you’d like to know if it makes a difference you might try it out.
It might be worth running for you rather than waiting 6 weeks.

Hey Nicholas, if you ever get tired of this software engineering business you should consider a career in marketing. 😉

Sweet. I’ve known for years that Firefox memory leaked, and that it was likely due to extensions (There was one that would knock it up to 2 GB memory usage in under an hour, some feed reader I used until Sage started working again), but I didn’t realize that ALL my memory issues were due to extensions. I knew there was a reason I didn’t like Adblock Plus, but Adblock stopped working. Ah well, all fixed now; Thank you.

It’s not necessarily the case that add-ons are responsible for *all* of the memory issues you’ve seen. But there’s a good chance that FF15 will improve things significantly.

This is soo exciting, I’ve been expecting this since version 9 and no major browser seem to do mush better than firefox, and I’d really hate to change my prefered browser if someone else had come up with this before you! Can’t wait till this will be released!

This is great news!!

Ever since Firefox 13 I have been having a better time using Firefox. I am now able to use Firefox for two days in a row without crashing (about 30+ tabs, 2-3 windows, some streaming videos). The memory is more stable. And I have about 89 add-ons which I am not willing to compromise (Firebug & Adblock Plus being some of them). Though I do encounter performance problems at times, but they are not as big an issue. Now I hardly use Chrome anymore as my secondary browser (though I do use it to play Chrome-only games at times).

Can’t wait for Firefox 15!! Keep it up, guys!!

89 add-ons? Wow. Yeah, Firefox 15 should be good news for you 🙂

I’m wondering, why you haven’t simply added a view “this is how much each of the addons you installed is using in memory at this time”? Would be good for the users to see which of their extensions is at fault.

Addons don’t have their own compartments to attribute memory to. Those made with the official addon-sdk (né Jetpack) have. Relatively few addons use it — most of the restartless ones do, and the proportion for new addons is improving. Even then, an sdk addon’s compartments might not account for everything the addon does. For example, an addon might use something like content scripts to inject itself into a page, and I’m not sure the layout part or even the script part can be separated from the page’s memory use.

It’s an obvious idea, but technically very difficult. Due to Firefox’s architecture, in a lot of cases there’s no way to determine which parts of memory are due to an add-on and which parts of memory are due to Firefox itself.

Having said that, Firefox 15 does give a *partial* idea, particularly for modern-style add-ons built with the Add-on SDK. Look at about:memory for the “compartment” entries that mention the names of add-ons. It’s not easy to use, but it does give you some information, and might be enough to identify some add-ons that are using excessive amounts of memory.

well, christ… do you think one day Firefox’s architecture will be designed in a way in which you can clearly see exactly where memory usage is coming from?

Probably not without a major change in how addon’s work. The historical FF addon model gives them full access to all of the browsers internals. That gives addon authors the power to do almost anything; it also means there’s no simple way to tell where a specific memory allocation comes from.

What’s the largest memory leak you’ve ever heard of?

I’m in college and while on a thin client using the school’s supercomputer cluster, I was kicked off and so was everyone else in the lab. Turns out that someone had left Firefox open overnight and it had acquired nearly all 60gb of memory available and had to be manually killed. That was… 2 months ago.

I got a day extension because of that lol, but 60gb… geez.

This is a blatant lie – unless that person was running a 64bit version, and even then FF can’t use that much RAM.

Cool stuff. Are you going to add in a metric somewhere to track the number of times the auto memfixer snags it? That way plugin builders can track it and fix their own issues still? Something like ‘leak on page close’?

No — there’s not much point warning about something that no longer causes problems. However, an error message will be sent to the error console if the add-on tries to use one of the references after it has been cut.

It’s great that Mozilla fixed the memory leak by preventing the root cause of the majority of the plugin leaks, which will help Firefox to regain trust in consumers; on the other hand, I feel that Mozilla should do more education in the plugin development documentations to explain and encourage more cautious memory utilization techniques. That’s huge.

@Nethercote: Is there anywhere we can request audit of a non-AMO extension? I and a number of other people use Reddit Enhancement Suite which is a Jetpack addon that seems to have a tendency to leak. FX15 seems to help but compartments still exist for ~1-5min even after closing all tabs and running a minimize-memory repeatedly.

Memshrink has tried to contact third party addon developers about leaky addons in response to bugs filed in in I’d suggest reporting any problems there.

I’ve looked at RES myself and I was unable to reproduce the problem. I think Kyle also failed to reproduce. To make progress we need very clear steps to reproduce — not just “browse reddit for an hour or two” but “login, view this page and this page and then do this”, or something like that.

If you can give me precise steps, that’d be extremely helpful. Thanks.

How much memory should Firefox be using? I’ve got a pretty standard setup with Greasemonkey, Wikilook, and ADP. FF seems to be around 300MB for me a lot. Now this clearly isn’t horrendous, but it still seems kind of large (2 to 8 tabs open normally).

This depends only on the websites you have open. For example: Facebook, Youtube, and Gmail are going to use more then wikipedia or google search.

Number of tabs themselves aren’t so important.

Soon firefox will show you how much each site is using in about:memory. =)

It’s impossible to say, because it depends entirely on what websites you have open in those tabs. I’ve written about this before:

300MB doesn’t sound ridiculous. But my real advice is to not worry about the exact memory numbers too much. Instead just pay attention to the performance — if it’s acceptable, don’t sweat over the memory numbers 🙂

Thanks both for the replies – you make good points. User-friendly profiling features would/will be pretty neat! Performance of Firefox is almost always fine for me, I just worry about RAM consumption sometimes when I’m working with some other quite hungry programs (yes Adobe – looking at you! :D), and sometimes 300MB of ram for a few low to moderately intensive sites seems like a bunch. I guess when most laptops come with 4+ GB of RAM, it hardly matters nowadays, but reducing memory usage is always a good thing for any program to work on!

about:memory already does partially show per-tab memory usage. Firefox 16 will improve that. But about:memory is pretty intimidating, so the goal after that is the provide a much simpler version that’s understandable to non-experts.

Navin – ESR version 10 will only get security updates – this is according to the ESR plan. You can however look forward to benefitting from these changes once we release Firefox 17 ESR is a few months.

Is there a similar project to MemShrink for Thunderbird? It’s great to see performance/memory improvements in Firefox but I use email just as much as web browsing.

Well the ‘leak fix’ must not have worked out to well as I use FF nightly >15 and the memory problem is horrible. I have 32GB of ram on the computer and inevitably 1/2 way through the day FF is using at least 8GB and running so slow that it’s not worth even using.

And yes, I do use add-block and Firebug. Without those addons I wouldn’t even consider using Firefox.

8GB is really unusual; I’d love to see the contents of about:memory when 8GB is being used. Can you email that to me? (But please note that I’m on vacation as of this morning, for 2.5 weeks, so I won’t be able to look at it until I’m back.)

Alternatively, you could file a bug and add “[MemShrink]” to the “whiteboard” field, and someone else might be able to investigate before I get back.


I am on of the devs really happy that the issue is being addressed. Thank you for the reply.

This was the exact conversation why I switch to Google Chrome a year ago. Firefox would run out of memory. Devs would blame plug-ins. When I told them all plug-ins were disabled, they didn’t believe me. I’ve seen the same story from dozens of people.



A year ago you would have been on Firefox 5 or thereabouts. Trust me when I say that the memory behaviour of Firefox 15 beta 1 will be way better. It’s another 10 versions on, and Memshrink has been working hard during the last year to get things sorted.

Complaining about how bad Firefox was a year ago is like complaining about the pcture quality on a 30 year old black and white TV. Things have moved on since then!

Download the latest beta release now and give it a go. You may well be pleasantly surprised.

With Firefox 15, is there a way to disable the incremental GC behavior and use older behavior instead? I ask because I have a strong suspicion this was at least partly to blame for my issues with 14. Even if this didn’t cause the insane memory growth I saw, the GC itself may have been what killed my performance while idling.

The fact that Mozilla still isn’t releasing proper changelogs, or at least not readable ones, makes this difficult to confirm. For all I know there was a completely different structural change that caused the issue. Can you pass along that we users need some way of knowing what’s different between 13 and 14, 14 and 15, and so on?

Go to about:memory and find the “javascript.options.mem.gc_incremental” option. Double-click to change it. I can’t remember if incremental GC is on by default in FF15, but I don’t think it is.

Change logs *are* available. See for an overview of the FF14 changes, and follow the “complete list of changes” link for full details. (I found that page in about 30 seconds by googling for “firefox 14 release notes”.) The notes for FF15 are also available, but they may change and the “complete list of changes” is not there yet because it will only be finalized just before the final release occurs.

Google is being generous to you, then, because to me it shows no such page. If I use the exact same search term without quotes, I get release notes for completely unrelated versions like 3.6.14, and the first few pages do not show the link you mentioned. If I put quotes around “firefox 14”, the other versions go away but your link still doesn’t appear on the first few pages; it ought to be the very top result, not buried on page 8 or wherever it ended up. And if I put the whole thing in quotes, the link doesn’t appear on any of the very few pages of results.

Now that I see the page, it’s not hard to see why I couldn’t find it; it’s actually harder to see how you found it at all, because again it doesn’t show up in even several pages of results from the search terms you used, and the page content clarifies why it wasn’t there. From a basic SEO standpoint, the page is terrible. Nowhere in the page itself does the version ever appear; it is only in the URL. The page is titled “Firefox Notes – Desktop” instead of the more appropriate “Firefox 14 Release Notes – Desktop Version”. The term”changelog” should probably appear somewhere or other on the full page, if only because it’s a common term that users will look for; at the very least “changes” should be there. Frankly given that the page content doesn’t say “Firefox 14” anywhere, there’s no expectation that Google should pick this page up in a search. Someone needs to bring this to the site developers’ attention.

It’s not even clear if all of the issues in the full list actually apply to that release, because bug 734946 appears in the list even though it’s clearly marked as applying to Firefox 13. And are new features listed anywhere at all in depth, or do we only have the main overview page to go on? Incremental GC isn’t mentioned in the overview page for 14 at all, nor in 15. (If incremental GC wasn’t responsible for that crazy CPU usage then I’m stumped as to what the actual cause was.) There’s actually no clear indication of whether this feature was turned on in 14, or 15, or if it has yet to be enabled.

Mostly I say this as a frustrated heads-up that Mozilla’s information isn’t reaching people who are actively trying to find it. The information that is there is thin on the main page, and difficult to sift and possibly inaccurate on the detailed page. And both pages are effectively Google-proof, because their content is written in such a way as to elude their indexing.

I found it with Bing previously. I just tried searching Google for “Firefox 14 release notes” (no quotes in the actual search) and was the first hit. Also, if you visit, there’s a “what’s new” link immediately under the giant green download button.

So feel free to complain about poor SEO, but I managed to find that page in three different ways in a total of about three minutes of looking.

Dear Nicholas,

I agree with LummoxJR. I tried finding the changelog myself, but I guess Google has optimized the results for you.

After updating from 13 to 14, I have had a lot of CPU and memory usage, which I put down to leaky addons. However, as Lummox states its quite possibly the incremental GC.

I know this is going out of this blog’s ambit, but your blog is currently the best Firefox point of contact known to people!

I dont know correct team to contact but is there anyway we could get three versions of the changelog.
1) The existing Whats New page as changelog lite.
2) A new more detailed changelog which mentions key features that have been turned on or off in an easy to comprehend format.
3) The full bug list as changelog expert. A lay person like me cant understand the highly technical info given in the bug filing.

Other than that, thank you for making FF useable. Really love all the work you have put into it. 🙂

Do you have specific steps to reproduce this?

File a bug on bugzilla, and whatever problem you seem to be having will get fixed.

What is TL;DR at the top for? Why post random text? Is it an error with my web browser? I don’t understand.

A better way to think about it is this: these add-ons are no longer buggy, because their reference-holding is no longer harmful.

Oh Mr Nethercote. how I wish the title of this post was true. *sigh*

Deep breath.
For the first time since finding out the memory bloat problem with my (old) router’s software and since the Hueyfix, using Aurora because Nightly really screwed things up about a month ago, today upon returning from work I received that fun present I’ve not seen for a while: total memory ballooning blowout. All of my physical memory and then some (virtual) was well and truly exhausted by Aurora.

I could almost cry. I really believed MemShrink had turned Firefox into a usable browser. Now I’m not too sure. You see not only is this browser the result of all the MemShrink effort but this time I’m even using a new profile through the Reset tool! Now after restarting the balloon session, I am slowly running out of memory again. MemChaser currently says 617MB and counting. I only have 13 tabs open, along with Sage in the sidebar. One of the tabs is about:memory whilst this is another one. So really I only have 11 normal tabs open and one of them is an error page. Additionally I have Flash disabled and none of the tabs are super-heavy JS applications like gmail. Actually another tab is the Add-On Manager.


I only have 16 Add-Ons installed and I bet you’ll think that’s a bit much but to me, each of them is reasonable. For example, two are actually due to me trying to help Mozilla: Add-On Compat reporter and MemChaser. Another two are there to tame the social widget and advertising JavaScript memory hog beasts: NoScript and Ghostery. Really though, I shouldn’t have to justify any of my Add-On use since the browser os heavily marketed on customizability as we have previously discussed. In fact most people now call Firefox the most customizable as the best way to distinguish it from the other browsers. Additionally I have been using all of the Add-Ons regularly for many weeks before and after the Hueyfix. I re-installed all the latest versions and restored my configs since the Reset tool doesn’t do that. I haven’t even re-installed TextArea Cache yet (better send this soon before Firefox eats all my memory and this post with it).

To try and start the debugging process, here’s my first thought: two Add-Ons are irregulars (I’ve been trying them in the last 10 days or so). Add-On Compatibility Reporter 1.1 and Ghostery which was running fine for about a week so I’m not sure that is a factor.

Another factor might be that I’ve enabled MemChaser logging after the balloon event. Generally I don’t have this enabled since I worry about it’s own impact on memory and performance (ironic).

I’ve tried to analyse about:memory but it has changed a lot since I last looked at it. There are no zombie compartments or other nasties listed. I do have iGC enabled. The usage does appear to have stabilised now between 6 and 700MB but hitting the Minimize Memory Usage button several times in about:memory has next to no effect. Now I’m even getting different measurements between MemChaser and about:memory. MemChaser says 690MB, about:memory says 732MB

Hmm by pasting that into Pastebin I notice Ghostery is eating 200+ MB if I’m reading it correctly. Is that your reading Nic? Presumably that isn’t normal. I wonder why that is happening. I’ve emailed you the MemChaser log.

Good luck investigating this issue. I presume no Add-On should be causing such big problems since the Hueyfix so I hope the answer is not merely: don’t use Ghostery. Oh yeah, in case there’s any confusion, I’m using Aurora 16.0a2 (2012-07-22).

Oh look, pd is bitching about Firefox. It must be a day of the week whose name ends in a ‘y’.

220.38 MB (30.10%) — compartment([System Principal], file:///C:/Documents%20and%20Settings/pdowling/Application%20Data/Mozilla/Firefox/Profiles/0314tpxg.default-1342856142686/extensions/

Ghostery is using at least 220MB.

39.07 MB (05.34%) — compartment([System Principal], jar:file:///C:/Documents%20and%20Settings/pdowling/Application%20Data/Mozilla/Firefox/Profiles/0314tpxg.default-1342856142686/extensions/%7B73a6fe31-595d-460b-a920-fcc0f8843232%7D.xpi!/components/noscriptService.js)

17.95 MB (02.45%) — compartment([System Principal], jar:file:///C:/Documents%20and%20Settings/pdowling/Application%20Data/Mozilla/Firefox/Profiles/0314tpxg.default-1342856142686/extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!/bootstrap.js (from: resource:///modules/XPIProvider.jsm:3595))

NoScript is using at least 57MB. The first compartment is obvious from the name, the second compartment is for XPIProvider.jsm, which is a Firefox JS module relating to add-ons; you can tell it’s being used for NoScript because of the common “extensions/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D.xpi!” substring.

“Oh look, pd is bitching about Firefox. It must be a day of the week whose name ends in a ‘y’.”

Wow is that inappropriate. Very mature.

The only exasperation and colour in my post was genuine heartfelt frustration not particularly aimed at any entity or individual. It would appear that my previous posts, when I’ve not turned masked my frustration but rather vented it sardonically, are still foremost in your mind when reading any new comments from me. Once again I apologize for my sardonic comments in the past.

I wasn’t ‘bitching’ (though I’d have every right to). I was in fact taking the time to communicate a bug situation to you and thus trying to help the Firefox project. In this sense, you’re comment is abusing a Mozilla volunteer and/or shooting the messenger. Not appropriate.

As you could probably read in my related email where I wrote “sorry to spoil your first days back from leave”, I am sympathetic to the implications of finding (seemingly) another bug in Firefox’s memory handling, especially one that appears to heavily contradict the brilliant Hueyfix. I’d appreciate it if you could take your own advice and use a “more civil tone” towards me as I am trying to maintain that same standard. You may think all I do is bitch but that’s factually incorrect. If you mine your blog comments I suspect you’ll see plenty of complimentary and appreciative posts. They’ll be outnumbered by comments on Firefox’s memory issues but that’s reality: if Firefox had no memory issues to mention, MemShrink would never have started.

Thanks for elaborating on the NoScript memory usage. I didn’t think to look for the unique identifier string in my extensions folder and enumerate that as NoScript. I guess this highlights a need to do that enumeration programatically when improvements to the about:memory page’s user-friendliness start to happen. Should I file a bug for this?

Lastly I realized a while back that any time you spend on this blog is time you are not using your incredibly valuable skills to help Firefox. I do not want to waste your time through contributing to any futile comment flaming sessions. Although it might not have appeared that way, it was with that mentality foremost in my mind that I wrote the above comment, supplied about:memory dumps, MemChaser logs and details of what was happening in the browser. In the biref time since disabling Ghostery after the initial ballooning experience last night, everything appeared to go back to normal.

You write 100s of words of complaints on most of the posts that I make — not to mention numerous other Mozilla blogs — and you’re “sardonic”. I let you know that I’m sick of this, and I’m “abusing a Mozilla volunteer”.

I genuinely suggest you go away and take a good, hard look at your communication style, and consider if it’s effective. If your conclusion is “yes”, then think about it some more.

Length of my comments seems to be a problem so I’ll try to be direct. This will mean less sugar coating however please give me the benefit of the doubt that my intentions are good.

If others bloggers have problems with my comments, let them say so.

Mozilla is far from immune to criticism. Most users don’t touch IRC or Google Groups. Blogs comments are as much a legitimate form for users giving Mozilla feedback as blog posts are for Mozilla communicating with it’s user base.

I’ll cut down the length of my comments by referencing bug data stored elsewhere (such at the Pastebin I did above).

I have explained and apologized for my sardonic posts more than once. They are not are frequent as you think but you may choose now to read all my posts in this manner. That is unfortunate but understandable. Please try to give me the benefit of the doubt in future.

Please try not to be one of those people who dismisses positive feedback and only focuses on the negative. My positive c0mments are usually shorter than my ‘issue’ comments. That does not make them any less heartfelt.

Unlike the majority of Mozillians, you live in the same city as me. Perhaps you’d like to take a swing at me and we can try to start afresh afterwards?

In addition to what Nick said, the error console shows a message when something attempts to access a closed window, so it is still possible to identify and fix these problems. But if they are left unfixed, you only get some slightly weird behavior, not huge memory leaks!

Does it mean that it will now be impossible to catch an addon leak that happens while the tab is still loaded? Sometimes addons just keep eating memory if you just leave a page open, I’m not sure how to debug this.

Btw, there is a probably another low-hanging fruit for MemShrink (it’s GDI objects, not memory, but it still can make FF effectively dead – only TaskManager will be able to kill it):

That’s a different kind of leak. In fact, it’s not necessarily even a “leak” as such, it could be legitimate behaviour, or just a badly written add-on.

Well, I switched off the most susceptible addons (and themes) and it still goes high.
A wild guess – it creates a window for each tab preview , and another window on top of each preview for the Close button. So you end up with at least 2n GDI objects for n tabs. It can be easily 3n or 4n if other GDI objects are being used and not properly released (e.g. graphical contexts/bitmaps used to display the preview, the favicon, the themed close button etc).
Also it looks like they are being cached for future use (which is good per se), so even when you close All Tabs, the counter doesn’t return back to normal.
If my understanding is correct, a fix could be probably to use just one window “All tabs” and draw previews, favicons and Close buttons on top of it as, instead of creating numerous subwindows per each preview. I’m not sure how will it interact with themes, though.

hi, I tried to reproduce the problem you mention and I reproduced it successfully. After experimenting a bit with it I realized that the gdi objects count will drop if you close the tabs and press Minimize memory usage in about:memory

Lanesy the original Sage works fine for me with Aurora 16.0a2 (2012-07-22) so presumably it should work on with FF15B1

With original, do you mean the 1.4.12?

That one hasn’t been worked on for over a year now, so security and some new qol-features(haven’t compared them lately though in this regard) aren’t up to par afaik.

Hence why I use the one from Higmmer.

Pinging the author would be more appropriate — though in this case, the page you link to warns that you may be on your own. Try this forum.

Quick question. Is it OK to reuse for example the graphs you have used in your posts? I would like to use for example the membench graph above in a post I am working on. I will of course include source info and backlink when doing so.

Firefox v 17 (currently in nighlies I believe) will be the next ESR release and so will be in use in many corporations, universities etc until late 2013. If there are any important fixes coming up, can you please do you best to get them into that release
Thanks for the good work, and sorry if I’m stating the obvious

Thanks for posting on this topic. I tried out the Aurora build today and was quite pleased to see the reduced memory/increased performance, and expected 2 ghost windows listed.

It seemed good for most of the day… but now after a typical workday I find I’ve got 1800MB allocated, 164 ghost windows, and a horribly slow, hitchy browser, as usual. So, still some work to be done here, I think. 🙁

(That’s with a mere four tabs in a single window, the heaviest of which is Gmail while the others are basically flat blog posts like this one. Disabled Firebug, disabled Ghostery…)

Hi Bret,

Please post the details of memory usage so the cause of the bloat can be investigated. Debugging such issues has become infinitely easier thanks to tools like about:memory.


Pairwise testing-

The problems with individual add-ons seem to be solved. An interesting
second generation test would be to take the top 20 add-ons and install all pairs- a few hundred combinations. The run through the top 100 sites a few times…

It might pick up a second generation of bug, where authors are assuming
exclusive access to resources….

For fun in might even be good to add all 20 at once- it would be reassuring
if firefox came through without too much in the way of leakage.

Like Bret Mogilefsky, I have been running 15 all day, and then closed every tab and had a ton of ghost compartments and leaks. 1.8GB ram used, 1 tab open.

Was hueyfix removed from 15 betas, cause this is no different to previous Firefox versions to me.

I have noticed that Firefox 15 beta is causing an explosion of memory usage for me. The memory usage is much higher than Firefox 14 beta, which used to be around 500MB under the same circumstances.

After a long period of web-browsing, I noticed that the memory usage was around 1.4 GB!! I closed all the other tab, ALL of them. Then opened an about:memory tab. Clicked “minimize memory usage” numerous times, but the usage did not go down. It seems every compartment is being leaked!

Firefox 15 beta seems to grow memory slightly faster, and not respond to closing of tabs. I have down graded to Firefox 14 release, and the problem is fixed.

See about:memory log here: leak.txt

Wow, that’s really bad. It looks like something is leaking your windows (as evinced by the large number of ghost windows in your about:memory dump). If I had to, I’d guess that one of your add-ons is reacting badly to our leak fix.

I’d very much like to get to the bottom of your issue, particularly if you can reproduce it. But I need you to file a bug at Please put [MemShrink] in the whiteboard field and one of us will have a look. You can also cc me (“:jlebar”) on the bug.

Do the not loaded tabs in the background take up memory? If yes, around how much do they take?

Thanks for posting on this topic. I tried out the Aurora build today and was quite pleased to see the reduced memory/increased performance, and expected 2 ghost windows listed.

This is wonderful news, but I can’t even use Firefox 14.0.1 because of a bug that prevents all right-click and drop-down menus from working. This is even worse because Ff 14 fixed critical security bugs, which I’m stuck with on Ff 13.0.1.

Unfortunately, this bug has not even been noticed by Mozilla or Ubuntu:

I’ve been enjoying the benefits of the memshrink effort, but if I can’t use the browser at all, what’s the point?

A wild guess – it creates a window for each tab preview , and another window on top of each preview for the Close button. So you end up with at least 2n GDI objects for n tabs. It can be easily 3n or 4n if other GDI objects are being used and not properly released (e.g. graphical contexts/bitmaps used to display the preview, the favicon, the themed close button etc).
Also it looks like they are being cached for future use (which is good per se), so even when you close All Tabs, the counter doesn’t return back to normal.

Comments are closed.