WPT tests for unspecified PopoverInvokerElement removing steps

[nt1m]

There is a WPT testing that moving/removing a PopoverInvokerElement hides its related popoverTargetElement when it was invoked from that button.

This doesn't look specified anywhere in the HTML spec. I don't have strong opinion on the behavior personally, but it would be nice to specify details like whether popoverTargetElement is still preserved after re-appending the element in the document.

cc @mfreed7 @josepharhar @annevk

[nt1m]

This is the WPT in question: html/semantics/popovers/popover-target-element-disabled.html

Looks like adding the disabled attribute or changing the input type also counts as cutting the hierarchy, basically anything that would make popoverTargetElement inactive.

[nt1m]

@rwlbuis @ziransun @asurkov Any opinion on this? There are 2 bits that WPT is testing don't seem to be in the spec:

1. If any of the conditions for an element to be an invoker stops being met (attribute change), then the associated popover should be hidden.
2. If an invoker is disconnected, the associated popover should be hidden

I think 2. is particularly problematic, since a web developer might just be moving the invoker and re-appending it somewhere else.

[josepharhar]

Apologies, here is a PR for the behavior which explains the purpose: #9048
If you're interested, additional context is in this code review where I added the test: https://chromium-review.googlesource.com/c/chromium/src/+/4115790

[asurkov]

@rwlbuis @ziransun @asurkov Any opinion on this? There are 2 bits that WPT is testing don't seem to be in the spec:

1. If any of the conditions for an element to be an invoker stops being met (attribute change), then the associated popover should be hidden.

2. If an invoker is disconnected, the associated popover should be hidden

I think 2. is particularly problematic, since a web developer might just be moving the invoker and re-appending it somewhere else.

It seems to me it's intuitive that if an invoker is disconnected then the associated popover is hidden. I'm not sure if re-appending the invoker button is a common scenario, but if it is, then I see how it can create a problem for the authors, because all they can do is to reimplement the popover invoker behaviour in JS, which is a bummer for web development for sure.

Also, I'm not sure exactly how the invoker disconnection is defined. From what I understand that a node removal is the case. But would display:none or @hidden, for example, be counted as well? What if a popover invoker is not on the screen (out of view or scrolled out)?

[josepharhar]

But would display:none or hidden, for example, be counted as well? What if a popover invoker is not on the screen

I don't think that style and layout things like this should affect whether an invoker is considered valid. The current algorithms only look at DOM state like connectedness, position in the tree, and attributes.

[nt1m]

Closed as I think the "check and close popover stack" behavior is gone from the spec and WPT.