Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#16481 closed defect (fixed)

Dialog memory leak. Dialog DOM is not destroyed after destroyRecursive()

Reported by: VictorWang Owned by: bill
Priority: undecided Milestone: 1.8.3
Component: Dijit Version: 1.8.1
Keywords: Cc:
Blocked By: Blocking:

Description

My problem looks like very similar to http://bugs.dojotoolkit.org/ticket/11329

It seem dijit.Dialog destroyRecursive() does not remove the Dialog DOM node. When user open/close a dialog multiple times, there will be some garbage DOM node in memory. I tried the dijit.Dialog testcase and found the problem can still be reproduced.

Here is the steps I reproduced.

  1. Open http://hostname:port/<mycontext>/dijit/tests/test_Dialog.html in sIEve.
  2. Click "Show Self-Destruct Dialog"
  3. Close the dialog.
  4. Open "Show in used" in sIEve. We can still see the dialog DOM node and the DOM is in orphan status.

Attachments (1)

DialogMemoryLeak.jpg (185.4 KB) - added by VictorWang 6 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by VictorWang

If there is any workaround to remove the Dialog DOM node, please let me know. Thanks.

comment:2 Changed 6 years ago by bill

Thanks for the report and steps to reproduce. I've seen this (or a similar) problem on trunk in #16478 but didn't think it was happening in the 1.8 branch. But I reproduced it in the 1.8 branch.

Dialog extends ContentPane, and ContentPane is calling dojo/html::_emptyNode(), which just maps to dojo/dom-construct::empty(). I tried changing it to call dojo/dom-construct::empty() directly but it didn't help.

I also wondered if there was a problem with destroying the Dialog while it was still sort-of in use, so I tried changing the test case as:

var dlg = new dijit.Dialog({
	id: 'SelfDestructDlg',
	title: 'Self-Destruct Dialog',
	content: 'This dialog will destroy itself onHide.<br/><input type="text" id="SelfDestructDlgInput" />',
	onHide: function(){
		setTimeout(function(){
			dlg.destroyRecursive();
		}, 0);
	}
});

That gets rid of most of the leak messages although there's still one left.

comment:3 Changed 6 years ago by bill

In [30197]:

Deprecate dojo/html::_emptyNode() since it just calls dojo/dom-construct::empty(). Also, add setTimeout() to test case to avoid so many warning from sIEve. Refs #16481 on 1.8 branch !strict.

comment:4 Changed 6 years ago by bill

Resolution: fixed
Status: newclosed

In [30198]:

Deprecate dojo/html::_emptyNode() since it just calls dojo/dom-construct::empty(). Also, add setTimeout() to test case to avoid so many warning from sIEve. Finally, update dojo/html test to be partially baseless (but still more work left). Fixes #16481 on trunk !strict.

Changed 6 years ago by VictorWang

Attachment: DialogMemoryLeak.jpg added

comment:5 Changed 6 years ago by VictorWang

Thanks for looking into this problem. I tested the code in comment2. But I can still see some orphan DOM nodes from the dialog. Please see the attachment.

Does destroyRecursive() only remove its content? Is it possible to remove all DOM node from dialog?

comment:6 Changed 6 years ago by bill

Milestone: tbd1.8.3

Are you running against the 1.8 branch? Because trunk is known to have issues, see #16478. If you are running against the 1.8 branch, try the test_Dialog.html. It's working for me.

destroyRecursive() is supposed to remove all the DOM nodes from the Dialog, not just the content. Because eventually destroyRendering() gets called, which then calls domConstruct.destroy(this.domNode).

Last edited 6 years ago by bill (previous) (diff)

comment:7 Changed 6 years ago by VictorWang

The problem was reported on dojo 1.8.1. The test_Dialog.html is from 1.8.1 as well. Is the 1.8.1 the "trunk" you mean?

comment:8 Changed 6 years ago by VictorWang

I tested the test_Dialog.html from 1.8.0. The problem can be reproduced too.

http://download.dojotoolkit.org/release-1.8.0/dojo-release-1.8.0/dijit/tests/test_Dialog.html

comment:9 Changed 6 years ago by bill

No, "trunk", 1.8.0, 1.8.1, and the 1.8 branch are all different things. Trunk is where we put changes like [30198] that will go into the next major release, i.e. 1.9. The 1.8 branch is where we put changes that will go into the next 1.8 point release, i.e. 1.8.3, for example [30197].

1.8.0 and 1.8.1 are versions of dojo that have already released. Like yesterday's newspaper, they will never change.

comment:10 Changed 6 years ago by VictorWang

Ok. Thanks for the explain. I ran the testcase on the released version(1.8.0 and 1.8.1). Can you see the orphan DOM node in sIEve when you run http://download.dojotoolkit.org/release-1.8.0/dojo-release-1.8.0/dijit/tests/test_Dialog.html

comment:11 Changed 6 years ago by bill

Yes.

Note: See TracTickets for help on using tickets.