Opened 9 years ago

Closed 9 years ago

#11329 closed defect (fixed)

ContentPane: does not release contained DOM node

Reported by: innou Owned by:
Priority: high Milestone: 1.6
Component: Dijit Version: 1.3.1
Keywords: Cc:
Blocked By: Blocking:

Description

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"];

Attachments (2)

test.html (1.3 KB) - added by innou 9 years ago.
HTML page demonstrating the leak
leak.html (1.6 KB) - added by bill 9 years ago.
more automated testcase. (1) press "show dialog", (2) note memory usage, (3) press "show dialog x10" 3 times, (4) note memory usage

Download all attachments as: .zip

Change History (10)

Changed 9 years ago by innou

Attachment: test.html added

HTML page demonstrating the leak

comment:1 Changed 9 years ago by 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];
} 

comment:2 Changed 9 years ago by bill

Component: DojoX WidgetsDijit
Owner: dante deleted
Summary: dijit.Dialog does not release contained DOM nodeContentPane: does not release contained DOM node

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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by innou

BTW, it happens in version 1.4.3 as well.

comment:5 Changed 9 years ago by 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?

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by bill

Milestone: tbd1.6

Changed 9 years ago by bill

Attachment: leak.html added

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

comment:8 Changed 9 years ago by bill

Resolution: fixed
Status: newclosed

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
Note: See TracTickets for help on using tickets.