DropDownButton/ComboButton/nested Menus: destroyRecursive() leaves orphaned sub-menus

[bill]

For ComboButton? or anything with a nested popup, the popup gets moved as a direct child of document.body to make positioning easier, but that means that ComboButton?.destroyRecursive() won't destroy the popup, and similarly Menu.destroy won't destroy any submenus.

This is only an issue when dynamically creating and destroying objects.

[sfoster]

getDescendants returns only the menu items, not the sub-menus, so destroyRecursive never gets an opportunity to remove those.

Is this really unique to popup-menus? if so perhaps Menu should supply its own getDescendants function to include these sibling sub-menu nodes which need to be considered descendants.

Bear in mind a sub-menu may be shared by other menus? (at least this was the case in 0.4) - not sure how to manage that. There's a parent/child relationship present in the popups, but its potentially dynamic? For sure though, if you create declaratively and nest a sub-menu, the expectation is that destroyRecursive should remove the lot.

Moving this to 1.0.1 (please?)

[bill]

Sub menus can no longer be shared by other menus.

This issue only applies to dynamically created/destroyed menus, which is in an unusual case, pluswhich I think there's a workaround, something like:

dojo.connect(dijit.PopupMenuItem.prototype, "destroy", function(){ this.popup.destroy(); });
dojo.connect(dijit.form.DropDownButton.prototype, "destroy", function(){ this.dropDown.destroy(); });

So I'm not going to fix for 1.0.1, but will do for 1.1.

[bill]

Same root cause as #3300.

[bill]

(In [11688]) Fix destruction issues with Menu. Fixes #1836. Refs #4902 (fixes it for Menu)

[bill]

(In [11690]) Fix issues with destruction of drop down menu of a DropDownButton?. Fixes #4902.

[bill]

(In [11735]) Fix regression in [11688] that was causing double destroy calls on same widget. Fixes #5326, Refs #1836, #4902.