Popup nodes can become orphaned in the document if the HasDropDown#HasDropDownCustomElement is released (and garbage collected) without ever having been attached to the document. For example, if a custom element does this::
var myTooltip = ...;
new HasDropDown.HasDropDownCustomElement({
behaviorNode: document.getElementById("behaviorButton"),
dropDown: myTooltip
});
When the custom element is destroyed, the myTooltip node is not, because it's in the document.
I think we can avoid that but temporarily attaching popup nodes to the document when they are being displayed, and otherwise detach them. Need to make sure they aren't initially attached.
It's a bit of a disruptive change though because the custom elements in the popup will keep getting detachedCallback() / attachedCallback() calls, and they might not respond correctly.
Currently, the "workaround", or rather the requirement, is that custom elements that create a HasDropDownCustomElement attach it as one of their (invisible) children, so that it gets notified when the custom element is detached. But this is error prone.
Popup nodes can become orphaned in the document if the
HasDropDown#HasDropDownCustomElementis released (and garbage collected) without ever having been attached to the document. For example, if a custom element does this::When the custom element is destroyed, the myTooltip node is not, because it's in the document.
I think we can avoid that but temporarily attaching popup nodes to the document when they are being displayed, and otherwise detach them. Need to make sure they aren't initially attached.
It's a bit of a disruptive change though because the custom elements in the popup will keep getting detachedCallback() / attachedCallback() calls, and they might not respond correctly.
Currently, the "workaround", or rather the requirement, is that custom elements that create a HasDropDownCustomElement attach it as one of their (invisible) children, so that it gets notified when the custom element is detached. But this is error prone.