Ticket #2056 (new defect)

Opened 2 years ago

Last modified 34 hours ago

ContentPane: Menu inside ContentPane not cleaned up on ContentPane destroy or reload.

Reported by: gbettencourt@… Owned by: bill
Priority: normal Milestone: 2.0
Component: Dijit Version: 0.4
Severity: normal Keywords:
Cc:

Description (last modified by bill) (diff)

Only occurs in IE ( I'm using IE7 ), reproduced with 0.4.1rc2 also.

The attached page has a two content panes, one which has a button to load a new page into the second pane. The page initially loaded by the pane contains a menu widget. After loading another page which does not contain a menu widget, clicking anywhere on the page will result in a "offsetWidth is null or not an object" js error. This only occurs if the new page does not have a menu, loading a new page with a menu works fine.

I also ran into another bug while creating this repro case, in dom.js dojo.dom.destroyNode does node.outerHTML= to prevent a memory leak. In my repro case, node can be undefined. We should insure that node is not undefined before trying to clear the outerHTML.

Attachments

test_Menu2_contentPane.html (0.6 kB) - added by gbettencourt@… 2 years ago.
repro case, place in tests/widget
test_Menu2_contentPane.2.html (0.6 kB) - added by gbettencourt@… 2 years ago.
a more simple test
test_Menu2_contentPane_pane1.html (297 bytes) - added by gbettencourt@… 2 years ago.
simple test
test_Menu2_contentPane_pane2.html (50 bytes) - added by gbettencourt@… 2 years ago.
simple test

Change History

Changed 2 years ago by gbettencourt@…

repro case, place in tests/widget

Changed 2 years ago by bill

  • milestone changed from 0.4.1 to 0.5

It doesn't seem valid for a ContentPane? to contain a Menu2 w/contextMenuForWindow="true". Can you try a simpler test, where the content pane just has a menu bar, or maybe a menu attached to a certain node?

Changed 2 years ago by gbettencourt@…

a more simple test

Changed 2 years ago by gbettencourt@…

simple test

Changed 2 years ago by gbettencourt@…

simple test

Changed 2 years ago by gbettencourt@…

test_Menu2_contentPane.2.html uses two simple pages (attached) as content for the pane, and still reproduces the problem.

Changed 2 years ago by gbettencourt@…

not sure if this is the correct fix, but overriding the destroy method in dojo.widget.Menu2 solves the problem:

destroy: function() {

dojo.widget.PopupManager?.closed(this);

},

Changed 18 months ago by bill

  • component changed from Widgets to Dijit
  • milestone changed from 0.9 to 1.0

The PopupManager? code has been completely redone for 0.9 so this probably isn't an issue anymore, but need to test.

Changed 16 months ago by bill

  • milestone changed from 1.0 to 1.1

Changed 12 months ago by bill

  • summary changed from js error when using a menu2 inside a content pane to Menu inside ContentPane not cleaned up on ContentPane destroy or reload.

See related bugs #3300 and #4980. This is currently broken because menus are moved to document.body and thus the cleanup doesn't work.

Changed 9 months ago by bill

  • milestone changed from 1.1 to 1.3

Changed 3 months ago by bill

  • owner changed from bill to sfoster
  • description modified (diff)
  • milestone changed from 1.3 to 1.2

Looks like this will be fixed by sfoster's conversion of ContentPane to use dojo.html.

Changed 3 months ago by sfoster

(In [14987]) Refs #5647 Refs #2056 Refs #4980

Refactored _setContent to use dojo.html._ContentSetter * a dojo.html._ContentSetter instance is created and stored on first use (at this._contentSetter) * each subsequent call to _setContent remixes in the config properties * _ContentSetter.empty() is called implicitly when you call this._contentSetter.set() - this will destroy any widgets from a previous set operation - including Menus, Dialogs etc, as the contentSetter.parseResults array keep widget references. This is partly redundant with the destroyDescendents() call in _setContent(), but catches this corner case. It does not fix the case where widgets have been created by the parser from inlined, initial content

* added a few unit tests to the test page to verify this behavior !strict

Changed 3 months ago by sfoster

The _setContent refactoring addresses half of this issue. When you call attr("content", ..) (or indirectly via attr("href"..) the content will be parsed for widgets, and a reference to those widgets is kept so they can be destroyed when the content is unloaded, or the widget itself is destroyed. However, widgets inlined inside the ContentPane? when the page is initially parsed are not provided to the ContentPane? to track, and the issue will still be present in that case.

Changed 3 months ago by bill

  • owner changed from sfoster to bill
  • milestone changed from 1.2 to 1.3

Ok, only half fixed. Given that a Menu/Dialog might exist outside of a ContentPane altogether, can't depend on ContentPane to fix this for us.

I think the final solution will be to leave a placeholder node where the Menu/Dialog was originally declared, or perhaps don't move the Menu as a child of <body> until you need to show it (and then move the Menu domNode back where it came from when the menu disappears)

In any case, the good news is that you can solve your problem in 1.2 by using href to load the ContentPane content.

Changed 2 months ago by bill

  • summary changed from Menu inside ContentPane not cleaned up on ContentPane destroy or reload. to ContentPane: Menu inside ContentPane not cleaned up on ContentPane destroy or reload.

See umbrella ticket #6954.

Changed 34 hours ago by bill

  • milestone changed from 1.3 to 2.0
Note: See TracTickets for help on using tickets.