Avoiding leaks in Mozilla JavaScript code (11:57 -0800)

I've written a document on Using XPCOM in JavaScript without leaking. This is for people writing JavaScript code in Mozilla applications or Mozilla extensions, which is how much of the user interface is written. One might think that JavaScript simply shouldn't leak, but that's not the case. It's possible to cause leaks in all garbage-collected languages. But there are also a few extra things to beware of when dealing with XPCOM through JavaScript, mainly due to the underlying reference counting model. I've tried to give a general summary of some of the basics of memory management before delving in to the Mozilla specifics. I hope this is accurate (and that the terminology I used is correct), since I'm not an expert on that.

And speaking of leaks, I've switched from using a non-debug build (of my current source tree) as my main browser to using a debug build. I log the output, which allows me to see all the assertions that I hit (with stack traces) and see when I'm leaking a lot of webshells or window objects. One of the things I've been doing with this information is trying to fix some of the major memory leaks that happen in normal use of Firefox. (I've also enabled some additional leak logging code to print leaks at shutdown.) However, fixing just the leaks that occur the way I use Firefox isn't enough, since other people use it in different ways and cause other code to be executed. So it would be great if other people in the community worked on (1) finding the leaks that occur in their normal Mozilla usage patterns, (2) reducing the steps to reproduce the leak to something small enough that it's easy to debug, and then (3) debugging the leaks.