[dojo-contributors] Unload, disconnect, leaks

Scott J. Miles sjmiles at turboajax.com
Wed Jun 27 13:14:05 EDT 2007

 > Right, it's for IE6 leak protection, but I haven't actually run tests,

Code using connect and subscribe has IE6 leak protection built-in.

So, especially wrt to util managers, there is no need to disconnect or 
unsubscribe at unload time to prevent leaks.

Also wrt Dijits in general, using connect and subscribe prevents the 
standard causes of leaks.

If there are Dijits that have other leak patterns, destroying the widget 
at unload time is not guaranteed to work. A dijit with such a leak must 
purposefully correct it at destroy-time. Ultimately this means we can't 
just have our head in the sand. As you say, the only way to be sure is 
to test it (continually).

So either we make it a rule that Dijits shouldn't leak, or we allow for 
them to have leak patterns (and require leak pattern removal at destroy 

In the latter case, short of a system for registering "leakers" at run 
time, I suspect it's likely easiest just to destroy all widgets as a 
catch all. But let's do it only when dojo.isIE < 7.

Scott J. Miles
TurboAjax Group

Bill Keese wrote:
> Scott J. Miles wrote:
>> Also, it looks like various Dijit entities are doing cleanup at unload 
>> time, and I wanted to ask about the rationale for that. This may be 
>> naiive, but (with the exception of leaky constructs in IE<7)...
> Right, it's for IE6 leak protection, but I haven't actually run tests, 
> especially not against the new 0.9 event code (dijit was originally 
> written against Dojo 0.4), nor the recently released patched IE6, so I 
> don't know if there's a real issue or not.
> Alex might be able to comment more since I'm basically just mimicking 
> the way Dojo 0.1 worked...
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list