It’s been a huge week for MemShrink.
Add-ons
I filed a bug on testing the top 100 add-ons for memory leaks. The majority of these add-ons are not available on AMO and so are not subject to the leak checking done during AMO reviews. The instructions and current test results are here. Randell Jesup helped identify some some add-ons with unclear identities, and Nils Maier and Archaeopteryx have both tested several add-ons. A month ago I said that add-ons that leak are the #1 problem for MemShrink, and this bug represents a huge step towards reducing that problem. We’ll need lots of additional help to test this many add-ons, so please feel free to jump in!
As far as I know, comprehensive testing of the most popular add-ons has never been done before. Although this testing is aimed at finding memory leaks, it’s quite possible it will uncover various other problems with add-ons. Indeed, it’s clear just from looking at the list that quite a few of the non-AMO add-ons are of dubious merit, and this has stimulated some interesting discussion on dev-platform about third-party add-ons, i.e. those that are installed into Firefox by an external program.
The following add-ons had leaks fixed or mostly fixed by their authors: McAfee Site Advisor, Ghostery, Spool, Screengrab (fix version), Roboform, UF Comment Board Tools, Geenstijl, Long URL Please, HTML Desktop Notifications.
Nils Maier greatly improved the documentation on common causes of memory leaks in add-ons. This was a MemShrink:P1 bug. That doesn’t mean the document can’t be improved further, however; it’s a wiki so please continue to add to it if you can.
Regression testing
John Schoenick’s excellent areweslimyet.com is getting close to being ready for a public unveiling. The site is currently live but password-protected, simply to prevent large numbers of people accessing it before it’s ready. (If you want a sneak peek, contact me for the password.) More importantly, it identified a large regression in memory consumption caused by the landing of the JS engine’s incremental garbage collector on February 19, which Bill McCloskey is investigating.
Tim Taubert improved Firefox’s regression testing to ensure that no new DocShell and DOMWindow leaks are introduced. This was a MemShrink:P1 bug because these leaks are quite easy to introduce. Tim wrote some more about this change here.
Cycle collector
Jan Honza Odvarko’s about:ccdump add-on made it onto AMO this week. Jan has been using this to hunt down some tricky leaks in Firebug.
Marco Bonardo fixed a leak in PlacesUtils.removeLazyBookmarkObserver() that I won’t pretend to understand, but which was a MemShrink:P1. Marco also fixed a leak that occurred after bookmarking a page, closing the window, and opening a new window.
Olli Pettay fixed an equally impenetrable (to me) leak involving nsFormFillController::mFocusedInput.
Kyle Huey fixed a leak in the About Firefox dialog.
Andrew McCreight added additional information to cycle collector’s error console logging, which helps with identifying and debugging cycle collector problems.
Miscellaneous
Jason Duell fixed an obscure leak involve web sockets.
Bill McCloskey fixed a minor JS engine leak.
I added a new memory reporter called “js/runtime/gc-marker”. It starts out at 256KB and I saw it reach 2.8MB when running MemBench. I also converted the existing source image reporters to the new style, which seems to haved fixed some bogus results in about:memory as a side-effect.
Quote of the week
Adam Overa of Tom’s Hardware did another browser Grand Prix. Devin Coldewey used the results from the Grand Prix to conclude that Firefox and Chrome are both great, and which you prefer basically comes down to a matter of taste. While that is an interesting conclusion, what caught my eye was this comment, by Balaji Viswanathan:
I guess the title could have been “All browsers suck equally bad now”. Firefox and Chrome have grown to become more resources hogs – closer to IE. These days I shudder to fire up the firefox as the memory leaks are terrible. Two hours of Firefox with a Facebook tab is enough to gobble up 25% of my memory. With Chrome, I would have 20 rendering processes showing up when I would have just 3 tabs open.
In the first 2 years of Chrome I had probably 2 or 3 crashes. These days, it crashes every week or so. I long for the 2006 era Firefox – clean, simple and lean. Its been a long time since I have used IE actively and with Safari lesser said the better. For the developers, we have to deal with the ultra slow update cycles of IE and ultraspeed update cycles of Chrome. In short, we are getting worse and worse in the browser arena. The market is ripe for a breakthrough.
“2006 era Firefox” would have been Firefox 1.5 or Firefox 2. Balaji may think he’s nostalgic for browsers of that era, but really he’s nostalgic for the web of that era, which was massively simpler than the web of today. If Balaji tried Firefox 1.5 or Firefox 2 today — with no HTML5 support, no JavaScript JIT and no hardware acceleration — today, I’m sure he’d quickly decide that 2012-era browsers aren’t so bad after all. I guess the interesting question is this: why do people blame browsers instead of websites for high resource consumption?
Bug counts
This week’s bug counts:
- P1: 28 (-5/+5)
- P2: 129 (-12/+7)
- P3: 83 (-8/+12)
- Unprioritized: 2 (-2/+2)
That’s a net reduction of one bug. But more importantly, there is lots of movement, which is great! It means that problems are being identified and fixed.
(Finally, commenters please note that I’ve turned on the WP-reCAPTCHA plug-in, and this the first post I’ve written since doing so. In my testing it’s worked fairly well. Hopefully it won’t cause problems.)