#3531 closed defect (fixed)
error: 'listener has no properties' sometimes appears in console (from bootstrap.js?)
Reported by: | davidb | Owned by: | anonymous |
---|---|---|---|
Priority: | high | Milestone: | 0.9 |
Component: | Core | Version: | 0.9 |
Keywords: | Cc: | alex | |
Blocked By: | Blocking: |
Description (last modified by )
Update: please see Simon's comment below for description of when this was introduced, and how to recreate.
Change History (16)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Oh I think this was my fault but I fixed it w/the most recent checkin to util/focus.js. Just forgot an if() check on the unsubscribe() call. I'll close for now but if it's still happening please reopen.
comment:3 Changed 14 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm still experiencing the problem after updating.
comment:4 Changed 14 years ago by
Description: | modified (diff) |
---|
comment:5 Changed 14 years ago by
Cc: | alex added |
---|
comment:6 Changed 14 years ago by
In general, you can get more information by using test_Menu_Debuggable.html, or by using the technique shown there for loading _base manually. I'm going to talk to Alex about having a way to make this happen via configuration.
However, it looks like this problem has to do with disconnecting at unload time. It's particularly hard to debug because FF and Firebug are not sane at unload time.
Fwiw, I'm not aware of any reason to do any disconnecting at unload time. I'm not sure why dijit.manager is doing this:
dojo.addOnUnload(function(){
dijit.util.manager.destroyAll();
});
comment:7 Changed 14 years ago by
The addOnUnload() calls in dijit.util.manager, and also in popup.js are just trying to avoid memory leaks. Not sure if there's a real issue or not but 0.4 did stuff like that. IE6 has been patched recently, and the event code is rewritten, so I think we should just remove those lines.
PS: oops, my previous comment said "focus.js" but I meant "popup.js"
comment:8 Changed 14 years ago by
IE6 for XP has been fixed. IE6 for Win2k will not get the fix. Most of our corporate clients are still using Win2k, so I would request the leak management remain.
comment:9 Changed 14 years ago by
comment:10 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
marking fixed. It was unclear why onunload would have been registered for widget system cleanup in the first place.
comment:11 Changed 14 years ago by
Milestone: | 0.9beta → 0.9 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
As per Scott's mail to dojo-contributors, we should be calling addOnUnload() for IE6 (only). At least that's the way I read it. Reopening but scheduling for 0.9:
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 time).
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.
comment:12 Changed 14 years ago by
PS: if we do decide not to destroy all widgets on unload (even for IE6), then we should get rid of that whole destroyAllWidgets() method.
comment:13 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:14 Changed 14 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Using sIEve (http://home.wanadoo.nl/jsrosman/) on a box with IE7, you can see objects leaked by loading dijit/bench/benchTool.html, change count to 1 (easier to see what leaked), change to "Create" method, click "Run Test", then click "about:blank" in sIEve to force onUnload. You should see 4 objects leaked.
If the cleanup code in dijit/_base/manager.js is run for IE7 as well, the leak disappears.
comment:15 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
OK, I'm running the cleanup code on IE7 too now, in [10043].
I'm also seeing this problem. It looks to me that the problem was introduced between the checkout for the nightly builds for 06-25 and 06-26.
I'm seeing the problem on:
http://archive.dojotoolkit.org/dojo-2007-06-26/checkout/dijit/tests/test_Menu.html
but not on:
http://archive.dojotoolkit.org/dojo-2007-06-25/checkout/dijit/tests/test_Menu.html
To reproduce: