Currently, the tabbrowser keeps browser elements alive after tabs are closed. This requires the browser binding to have a destroy() method, and when things that need to be added to the destroy() method aren't we can end up with substantial memory leaks, including the documents that were in the tab. An example of such a leak is bug 489520. However, even without that, there's still a small leak of elements that we don't need around anymore, but are still keeping around. In the cycle collection traces from debugging bug 489520, I observe the following: * the only reason the browser element is kept alive is because it is referenced from the "linkedBrowser" property of the tab element. If we disconnected that at appropriate times, I think we'd stop leaking browsers, though we'd still be leaking tab elements. * the tab elements are leaked for multiple reasons: + one is that they're sometimes entrained by the closure attrChanged in the tabbrowser binding's addTab method. + another has something to do with XBL insertion points: there are various nsXBLInsertionPoint objects whose mElements array has the removed tab element that's reachable in a whole bunch of ways from other elements (presumably still in the document, although I'm not sure)

(In reply to comment #0) > + one is that they're sometimes entrained by the closure attrChanged in the > tabbrowser binding's addTab method. Dão spun this off into bug 489628 and fixed it.

(In reply to David Baron [:dbaron] from comment #0) > * the only reason the browser element is kept alive is because it is > referenced from the "linkedBrowser" property of the tab element. If we > disconnected that at appropriate times, I think we'd stop leaking browsers, > though we'd still be leaking tab elements. This was done in bug 664672.