I'm filing this as a toolkit bug rather than a mail bug because I strongly suspect it's a toolkit problem. Opening the main mail window (run "mozilla -mail", and exit) leaks a GlobalWindowImpl that is not garbage collected. There is a single leaked JS root: an nsXPCWrappedJS (that is an nsIController). It is leaked from an nsXULControllers object (it is inserted into that objects supports array and never removed). The leaked nsXULControllers object is leaked from a GlobalWindowImpl. This seems like a simple circular reference problem that should be fixed by adding |mControllers = nsnull; // Forces release| to |GlobalWindowImpl::CleanUp|. However, that doesn't fix it. I have no idea why? Where did I go wrong?

A few more thoughts. I previously thought that CleanUp was called because the window's script object was not rooted. However, it could be that the window's script object was never requested. (How much could such a window be used? Maybe it was some sort of prototype?) The mControllers=nsnull might be a good idea anyway, whether it's the problem here or not. I think once in the past I saw it reduce the fallout from another leak.

The changes for bug 55426 may make this harder to detect.

->danm for investigation. Please nominate for rtm or future as appropriate.

I'm seeing a very similar leak in the message compose window.

Hmmm, nsHTMLInputElement and nsHTMLTextAreaElement also have an nsXULControllers. I bet that's the problem. If so, is releasing it on SetDocument(null) the right solution?

Well, it didn't work.

It didn't work because nsGfxTextControlFrame2::Destroy calls GetControllers. At least, that's why fixing the nsXULControllers leaked from the input element didn't work. I still don't know if that's the cause of the bigger leak.

Well, I fixed the leak of the nsXULControllers from the input element (by adding a SetControllers method and calling it in nsGfxTextControlFrame2::Destroy), and the rest of the leak didn't go away, so the cycle is through the nsXULControllers object that is the mControllers of the GlobalWindowImpl. So what's wrong here? Is GlobalWindowImpl::Close() not being called?

Taking this bug since I've been working on it.

Nice. r=waterson

I should add, I'm assuming you only want r= on the last patch?

sr=brendan@mozilla.org. Only thought is to subroutine so that CleanUp and SetDocShell both call a BreakCycles method (or a better-named one). Your call. /be

Hmm. Perhaps a more general fix for this type of leak would be to set mDocument to null in GlobalWindowImpl::SetDocShell. This might break a lot of potential cycles, but I'm not sure whether it would break all the ones we need to break...

r=waterson

dbaron, you need to patch text area and input element as well, since they have controllers also. sr=hyatt on the XULElement, but please make the same patch to the other elts before checking in.

Never mind. Odds are slim it would become a problem. Fire away.

Fix for nsXULElement checked in 2001-03-09 19:18 PST. I need to investigate whether we need a: * Input/TextArea fix * general fix in GlobalWindowImpl so leaving the bug open for now.

Moving to 0.9.1 for dealing with the remaining issues.

dbaron, is this still reproducible?

This is ancient and probably not relevant any more.

based on comment 23, fixed