ContentPane: does not release contained DOM node

[innou]

dijit.Dialog has a dojo.html._ContentSetter object used to set dialog's content. When destroyed, dialog does not release this object. This results in memory leak at least in IE 7.0/8.0 since _ContentSetter maintains reference to DOM node designated as dialog's content.

Dialog is created as

var dialog = new dijit.Dialog({
  title: "Title"
});

var iframe = document.createElement("iframe");
dialog.attr("content", iframe);

dialog.show();

and destroyed as

setTimeout(function() {
  dialog.destroyRecursive();
}, dialog.duration);

There is a workaround that helps: after destroyRecursive() delete _contentSetter from dialog:

delete dialog["_contentSetter"];

[innou]

HTML page demonstrating the leak

[innou]

I wanted to note that deleting only _contentSetter does not free all memory. Memory is fully released when all properties are deleted:

for (var p in dlg) {
  delete dlg[p];
} 

[bill]

The browser's garbage collection should handle all of this automatically... are you actually seeing memory usage go up, and if so on which browser?

Marking component as Dijit although it could be HTML.

[innou]

Probably the browser should handle this (though I have doubts it is solely browser issue), but it doesn't. As I already noted, I observe steady memory growth in IE 7.0/8.0. You can easily reproduce it using the test page that I attached.

[innou]

BTW, it happens in version 1.4.3 as well.

[bill]

Ah sorry, I didn't notice that you had already listed the browser.

I can see memory usage going up when I repeatedly press the "show dialog" button, but then it goes down when I reload the test page. Is that what you meant?

[innou]

Yes, it is. For one-page application where the page might be never reloaded this is a major issue. The contents of not released iframe can easily occupy 10 or more megabytes.

[bill]

more automated testcase. (1) press "show dialog", (2) note memory usage, (3) press "show dialog x10" 3 times, (4) note memory usage

[bill]

It seems like the problem has mostly gone away in trunk, and further that the proposed fix doesn't help anymore, although it is useful in 1.4. Here are my numbers about memory increase for showing 30 dialogs, with and w/out the proposed fix. (I ran most of the tests twice.)

trunk:

• 30 dialogs / 2m, 0m
• w/fix: 30 dialogs / 1m, -1m

1.5

• 30 dialogs / 6m
• w/fix: 30 dialogs / 6m

1.4

• 30 dialogs / 16m, 13m
• w/fix 9m, 18m