There are multiple d-popup nodes that show up in the document.
Here's what's happening:
Combobox (at least on mobile) recreates the popup every time it's opened. So to be simple and consistent, the popup (and wrapper) should be destroyed on closeDropDown().
Instead, Combobox leverages HasDropDown to delete the old popup.
HasDropDown was written to support two cases:
1) a new dropdown is created every time you call openDropDown() (like what Combobox does)
2) the same dropdown is reused every time.
So HasDropDown keeps track of the old dropdown, and then if a new one is created, loadDropDown() deletes the old one:
Close role Combobox popup. HasDropDown#closeDropDown() saves pointer to this._previousDropDown, and then Combobox is focused.
Click anywhere on the screen, blurring Combobox.
Combobox’s HasDropDown#_deactivedHandler() is call, which calls closeDropDown() again for the Combobox, losing reference to this._previousDropDown.
So at a basic level, the bug is that HasDropDown#closeDropDown() isn't idempotent, specifically that this code loses the reference to the dropdown when run twice:
On ComboPopup.html test page:
There are multiple d-popup nodes that show up in the document.
Here's what's happening:
Combobox (at least on mobile) recreates the popup every time it's opened. So to be simple and consistent, the popup (and wrapper) should be destroyed on closeDropDown(). Instead, Combobox leverages HasDropDown to delete the old popup.
HasDropDown was written to support two cases:
1) a new dropdown is created every time you call openDropDown() (like what Combobox does) 2) the same dropdown is reused every time.
So HasDropDown keeps track of the old dropdown, and then if a new one is created, loadDropDown() deletes the old one:
However, this isn't working consistently:
So at a basic level, the bug is that HasDropDown#closeDropDown() isn't idempotent, specifically that this code loses the reference to the dropdown when run twice:
At a more philosophical level, maybe the bug is that this code is all too complicated.
See also related ticket #487.