A month ago I finished reading all UNCONFIRMED bugs filed against FIREFOX that had last been modified in 2006. Out of the many 1000s of bugs I read, ~1418 were tagged with a CLOSEME on their whiteboard, in hope that they could be closed. After waiting 3 weeks after each bug was tagged in the hope that the reporter would close their bug (many of which did), I reread the remaining open bugs and triaged as many as possible. The combined results of the reporter closing their bug, and myself and other triagers closing bugs I had tagged, is that 1030 bugs were closed!

However, this means there are ~387 bugs that remain open that have been whiteboarded with one of CLOSEME 06/27, CLOSEME 07/05, CLOSEME 07/09 or CLOSEME 07/14 - and such bugs I do not know what to do with. The bar for closing bugs was quite high; the bug report had to be of no value what so ever or to be incomplete to the point that it was useless. The bugs that remain open are bugs that are filed against an OS I don’t use, are too technical for me, are badly written but someone with enough knowledge and time could tease some information out of, or are untestable by me.

So, the questions remains, what to do with these bugs? Perhaps, as Wayne Mery suggests, they could be made the focus of an upcoming testday. But if anyone is CC’d to a bug with such a CLOSEME tag on please feel free to re-evaluate the bug and close it if possible.

This work is very boring really (no, honestly!), but it is nice to clean bugzilla up so much. I will be starting on UNCONFIRMED FIREFOX bugs in 2007 now, on a month-by-month basis. But I’m not going to spend so much time and effort as I did for the 2006 bugs.

And so to finish, again, with a nice graph of what we have achieved - about 2,000 bugs closed in total. (And if Gerv fancies EXPIRING some bugs, there’s 237 UNCONFIRMED bugs tagged with CLOSEME that are filed against Firefox 1.5)

Recently I’ve been investigating extensions and whether any cause memory leaks on Firefox Trunk builds. The two things I am most interested in are:

The first point is common sense; an extension leaking memory can make firefox look bad and could lead to problems whilst browsing. The second point is more interesting, since it could indicate a problem with the new XPCOM Cycle Collector.

Of course there are serious limitations as to what one guy can test. There are 1000s of extensions available for firefox, there are many different codepaths within a single extension and there is also the possibility of memory leaks caused by the interplay between two or more extensions. Thusly, my scope for these tests was quite small; I individually tested the top 20 extensions listed on AMO plus a few of the extensions that I personally use.

For testing I was using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007071803 Minefield/3.0a7pre ID:2007071803, a new profile and had extensions.checkCompatibility set to false to allow the installation of extensions that would not otherwise install on trunk builds. I installed one extension at a time and then tried using it, setting different options and generally screw around on firefox for a while. Then firefox would get closed and the nspr.log analysed for leakage. In these brief tests, I was unable to make the following extensions leak:

So with my testing I could not get leak-gauge.pl to report any memory leakage with these 18 extensions. (Disclaimer still applies: I couldn’t possibly test all code-paths and extension interplay could perhaps cause memory leakage!) Now onto what I did find:

And that concludes my testing. A good result considering the massive changes that the XPCOM Cycle Collector made.

Over the last 4 weeks or so, as part of the drive to lower the number of unconfirmed bugs, I’ve read every bug filed against Product:Firefox that was last touched in 2006, whose status was UNCONFIRMED and whose keywords were not hang, crash, regression or mlk, with the intention of closing as many as possible.

My main target were bugs filed against the now no-longer-supported 1.5 branch, bugs involving websites that have long ago been redesigned, bugs involving plugins that now have newer versions, end-user support questions, bugs where the reporter was asked to provide more information but didn’t and bugs that I recognise were caused by an extension. In such bugs I have asked the user if they still see the problem in the latest firefox 2 release, and if they don’t, would they please resolve the bug as WORKSFORME.

I have no idea how many bugs I read in total (~2000+ I’d guess) but the bugs I did comment in were whiteboard tagged with CLOSEME. The four tags I have used were “CLOSEME 06/27″, “CLOSEME 07/05″, “CLOSEME 07/09″ and “CLOSEME 07/14″. Many (200+) such bugs have been closed by the reporter themselves (and the CLOSEME tag removed) which is excellent news. The number of bugs that I’ve tagged that remain open now stands as ~1,225. Over the comming month or two I plan to go through these and close as many as is correct to do so.

It should be noted I am erring on the side of caution here; I would rather leave a bug open and unconfirmed than close it erroneously. But at the same time it should be understood that if a bug is closed as INCOMPLETE, this does not mean it contains no useful information. Rather that the source of the information is no longer forthcoming, and so the bug report is unlikely to progress any further.

Bugs of a technical nature, bugs that include a discussion with names I recognise and bugs that I just plain didn’t understand I have not commented in, and so remain open and unconfirmed. (Currently standing at ~684 bugs filed against Product:Firefox last touched in 2006.)

And to finish, a nice graph of how we’re progressing.

Today I set myself the task of visiting all the sites on the Alexa Global Top 500 Websites list to see if any of the pages caused memory leaks on the Firefox trunk. I was using an hourly build (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070620 Minefield/3.0a6pre ID:2007062013) which is the build just after the new text-frame stuff was turned on. Using a new profile, I would open 10 or 15 sites in new tabs at a time, wait for them to load, then close firefox and analyse the nspr.log for leaks using dbaron’s perl leak-gauge.pl script.

After a whole load of clicking (and putting up with anoying sites that used audio) I ended up filing a whopping two bugs: 385082 which covers apparent leakage on wordpress.com (oh, the irony!) and 385251 which covers a memory leak when adding or deleting a bookmark.

So out of loading 500 different websites, I only found one which caused a memory leak. Although it should be noted that I didn’t do any navigating around each website, this is still a great result considering all the changes that have gone on in this area with Graydon’s XPCOM Cycle Collector. Next up, seeing if I can catch any naughty extensions leaking memory!

Well after registering this blog over 6 months ago I’ve finally got round to adding a little content and making my first post. Wahoo! There’s not much to read here at the moment, but over the coming weeks and months I hope to add some more stuff and start to write about how I feel the Firefox project is going. I’ve been following Firefox development since Phoenix 0.6 so I’ve got a bit of history already, having been through three release-cycles (1.0, 1.5 and 2.0), and due to an administratative mix-up at Mozilla HQ I was accidentally ;c) invited to the Firefox 2006 summit where I met loads of cool people and really felt the energy and passion everyone involved in Mozilla give off about wanting to make the web a better place.

In the past I’ve found myself writing something about Firefox and then not posting it, unsure as to where exactly I should post my semi-random brain-spew; to the wiki? to the newsgroups? to the MozillaZine forums? I really didn’t know then, but I do now - they’ll get posted here! That’s the beauty of Firefox being such an open project; anyone can follow what’s going on and write about it.

I’m not a Firefox programmer (I really need to get my PC sorted so I can at least start to build it myself) but I do quite a bit of bug triage and nightly testing, and lots of reading about what other people are doing and what plans are being made. And I need to get involved in QA more because that’s something anyone can do and an area where more help is always welcome. In the past weeks, as part of the drive to Lower the Number of Unconfirmed Bugs, I’ve been going through 100s of such bugs filed against Firefox and trying to close as many of them as is correct to do so. There’s been quite a bit of response from peoples’ bugs I have commented in, with many being closed WORKSFORME by the reporter themselves.

If anyone has any ideas as to other content I could add here then please let me know, but without further ado, let the blogging commence!