Opened 12 years ago

Closed 12 years ago

Last modified 7 years ago

#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 davidb)

Update: please see Simon's comment below for description of when this was introduced, and how to recreate.

Change History (16)

comment:1 Changed 12 years ago by simonjb

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:

  • load above page into FF
  • open the Error Console or Firebug console
  • reload the page

comment:2 Changed 12 years ago by bill

Resolution: fixed
Status: newclosed

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 12 years ago by simonjb

Resolution: fixed
Status: closedreopened

I'm still experiencing the problem after updating.

comment:4 Changed 12 years ago by davidb

Description: modified (diff)

comment:5 Changed 12 years ago by simonjb

Cc: alex added

comment:6 Changed 12 years ago by sjmiles

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 12 years ago by bill

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 12 years ago by guest

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 12 years ago by bill

(In [9324]) dojo.addOnUnload() causes errors in Firefox console; commenting out for now. Refs #3531.

comment:10 Changed 12 years ago by alex

Resolution: fixed
Status: reopenedclosed

marking fixed. It was unclear why onunload would have been registered for widget system cleanup in the first place.

comment:11 Changed 12 years ago by bill

Milestone: 0.9beta0.9
Resolution: fixed
Status: closedreopened

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 12 years ago by bill

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 12 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [9413]) Only run cleanup on page unload for IE6. It causes errors on FF and we think it's only necessary for IE6 anyway. Fixes #3531.

comment:14 Changed 12 years ago by guest

Resolution: fixed
Status: closedreopened

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 12 years ago by bill

Resolution: fixed
Status: reopenedclosed

OK, I'm running the cleanup code on IE7 too now, in [10043].

comment:16 Changed 7 years ago by bill

Note: cleanup code was removed completely in [28551].

Note: See TracTickets for help on using tickets.