Opened 11 years ago
Closed 11 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)
Change History (10)
Changed 11 years ago by
comment:1 Changed 11 years ago by
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 11 years ago by
Component: | DojoX Widgets → Dijit |
---|---|
Owner: | dante deleted |
Summary: | dijit.Dialog does not release contained DOM node → ContentPane: 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 11 years ago by
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:5 Changed 11 years ago by
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 11 years ago by
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 11 years ago by
Milestone: | tbd → 1.6 |
---|
Changed 11 years ago by
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 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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
HTML page demonstrating the leak