Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9778 closed defect (fixed)

AccordionContainer: incorrectly destroyed in ContentPane

Reported by: vovasty Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.3.2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

it overrides destroy() function with destroying buttons, but also should override destroyRecursive()

in some cases destroyRecursive() called before destroy() (for example, when accordion container is inside ContentPane, and we will set new content for ContentPane, it will call destroyRecursive(), and after it destroy())

destroyRecursive: function(){
	dojo.forEach(this.getChildren(), function(child){
		child._buttonWidget.destroy();
	});
	this.inherited(arguments);
}

Attachments (1)

test_AccordionContainerDestroy.html (2.0 KB) - added by vovasty 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by bill

What you mean by "it" -- AccordionContainer or ContentPane?

Anyway, destroyRecursive() calls destroy() so I don't see a reason to override destroyRecursive(). Can you attach a test case showing the problem?

Changed 10 years ago by vovasty

comment:2 Changed 10 years ago by vovasty

place test under dijit/tests/layout/

ContentPane? calls destroyRecursive() BEFORE destroy(), it will destroy all children of accordeon (eg, child ContentPane?), after it will be called destroy() - but all ContentPanes? gone, and buttons will remains

comment:3 Changed 10 years ago by bill

Milestone: tbd1.4
Owner: set to bill
Status: newassigned

Thanks for the test case!

OK, I see, AccordionContainer.destroy() code runs but it has no effect since getChildren() returns [].

comment:4 Changed 10 years ago by bill

Description: modified (diff)
Summary: AccordeonContainer incorrectly destroyed in ContentPaneAccordionContainer: incorrectly destroyed in ContentPane

(Just fixing spelling so future searches can find this ticket.)

comment:5 Changed 10 years ago by bill

Seems like the root issue is that AccordionContainer.destroyDescendants(), and for that matter TabContainer.destroyDescendants(), don't clean up the buttons. This will be easier in 2.0 once #5796 is implemented but in the meantime I'll fixe the code, probably in StackContainer.js.

comment:6 Changed 10 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [19967]) Refactor StackContainer destruction to make sure that the accordion buttons get destroyed. The problem wasthat after removing the children further code that called getChildren() was doing nothing. Fixes #9778 !strict.

comment:7 Changed 10 years ago by bill

(In [19970]) TabContainer? fixes:

  • Make children of TabContainer? w/doLayout=false get laid out properly (but not resized to fit TabContainer?).
  • Make sure ScrollingTabController?.resize() is called (to layout arrow buttons etc) even when doLayout=false (fixes #9004)
  • Convert pane2button[] and pane2handles[] key to be pane id (a string) instead of pane itself (an Object). The pane itself seemed to be causing lookup problems on IE6 in the test_TabContainer_noLayout.html test.
  • also a fix related to destroyDescendants() for TabContainer? to prevent double-destroy of tab buttons (refs #9778)

!strict

Note: See TracTickets for help on using tickets.