> However, in IE4-7 the JS garbage collector isn't responsible for handling DOM nodes and vice versa.
It's a little sad that you don't expand on this, for those in the audience who do not know of this issue. So I will:
In IE up to IE7, Javascript lives in the jscript engine (equivalent to one V8, Tamarin, Rhino or what have you), but DOM objects are actually COM objects. COM objects are handled with a COM runtime, and there is an interface through which jscript interacts with COM.
MSIE4-7 has no issue with jscript circular references (it uses a mark & sweep GC, immune to the issue), and the COM engine ensures there are no issues with circular references in the DOM (COM uses refcounting but — as in Python for instance — has cycle detections).
Issues, as usual, arise at the boundary: if a jscript object has a reference to a (COM) DOM node, or a DOM node has a reference to a jscript object, it creates a foreign reference which will not be cleaned up until the holder object on the other side of the interface is done with.
For both garbage collectors, those foreign references are completely opaque, the only thing they know is that those exist but they have no way to know what happens on the other side of the jscript-COM interface. This means if there is a cycle crossing the boundary (twice), neither garbage collector is able to clean it up. And there is no Breach, able to take care of boundary issues such as this.
And it leaks.
A lot.
In fact, it leaks so much that a few years ago a tool was tested with the sole purpose of reloading a page and carefully monitoring the objects which fail to be cleaned: drip.