#4902 closed defect (fixed)
DropDownButton/ComboButton/nested Menus: destroyRecursive() leaves orphaned sub-menus
Reported by: | bill | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
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.
Change History (8)
comment:1 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Summary: | DropDowb/ComboButton, nested Menus: memory leak on destroy recursive → DropDownButton/ComboButton/nested Menus: memory leak on destroyRecursive() |
comment:2 Changed 13 years ago by
Milestone: | 1.1 → 1.0.1 |
---|---|
Summary: | DropDownButton/ComboButton/nested Menus: memory leak on destroyRecursive() → DropDownButton/ComboButton/nested Menus: destroyRecursive() leaves orphaned sub-menus |
comment:3 Changed 13 years ago by
Milestone: | 1.0.1 → 1.1 |
---|
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.
comment:5 Changed 13 years ago by
comment:6 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [11690]) Fix issues with destruction of drop down menu of a DropDownButton?. Fixes #4902.
comment:7 Changed 13 years ago by
comment:8 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
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?)