[Greasemonkey] Possible source of memory leaks

Jeremy Dunck jdunck at gmail.com
Sat Jul 9 00:10:19 EDT 2005

On 7/7/05, Nikolas Coukouma <lists at atrus.org> wrote:
> So, they create a dummy object with the document as the owner. This
> object persists until the document is  no longer displayed.

The way i read it, they add a ref from the document to the expando'd
obj.  Is there really a dummy obj involved, or did I misinterpret?

> This means that adding properites to XUL elements is Very Bad because it
> will hold onto memory until the window is closed.

Thanks for that interpretation.  I read the article w/o putting it
together-- in XUL, our document  has the lifetime of the chrome

> I'm not sure if this is pertinent at the moment, but it seems like
> something we'll trip over later, if we haven't already.

Yes, it's pertinent now.  Because of the bug where removed elements
lose their listeners, command callbacks are called with expando props.

Something like:
menuitem.__cb = content-supplied-func;
and later:
and later...
menuitem.addEventListener("command", menuitem.__cb);


I don't see an immediate way around this.
It wouldn't be so painful if we could get at these specially added
refs and remove our objects when we liked.

I also just happened on this bug, which nails us again:
"calling addEventListener with a closure holding a content node leaks
the document"

I'm now for maintaining a content-based collapsible menu reg UI and
getting away from content-intiated XUL altogether.  These are meaty
Moz bugs, and it's starting to hurt.

I just had to admit to a coworker that his FF ate 200MB cuz of us.   I
imagine there are many more similarly annoyed.

... I'll look at the rest of what we're doing with an eye towards
expando/addEventListener-leakage, too.

Thanks, Nik.

Meanwhile --- get everyone to vote on these bugs.  :)

More information about the Greasemonkey mailing list