dojo.connect has two parts in 0.9.
code, while _base/event.js contains the DOM aware version, including the
browser event normalization magic.
IE<7 has a well known leak pattern wrt circular connections between DOM
and JS. Former solutions for this leak pattern have tended to impair the
general GC-friendliness of the connect code.
I believe the new system is GC-friendly on most browsers, while still
protecting against connect leaks on IE<7.
Running this by contribs for sanity check, before embarking on full
* Are there mistaken assumptions regarding the GC?
* Are there other memory leak patterns to worry about?
* Are there browsers othan than IE that have an issue with DOM/Js
The implementation of dojo.connect has the source maintain a collection
of target references.
Because only the source holds the target references, disposing the
source is enough to remove all references created by dojo.connect. In
other words, there is no bookkeeping information created by dojo.connect
that will be problematic for garbage collection.
Sometimes a target circularly references a source. This is only a
problem on IE prior to version 7, where circular references between DOM
If dojo.connect detects a DOM node as the source, it passes control to
AddListener Fast Path
On non-IE browsers, dojo. addListener uses the Node.addEventListener
AddListener on IE 7
On IE7, addListener uses dojo.connect.
AddListener on IE <7
On IE6 and below, addListener uses a custom connection with a hash map
to prevent the source from referencing any targets directly and avoiding
any circular reference leaks. This solution requires storing a list of
targets separately. So the target references are not automatically
released with source, as with the fast-path implementation. Calling
disconnect will release a target.
Scott J. Miles