AccordionContainer: incorrectly destroyed in ContentPane

[vovasty]

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);
}

[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?

[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

[bill]

Thanks for the test case!

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

[bill]

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

[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.

[bill]

(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.

[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