Popover: Implicit anchor element removed too early

[jakearchibald]

What is the issue with the HTML Standard?

https://codepen.io/jaffathecake/pen/Qwyjyma?editors=1111

In the demo, when you hide the popover (by clicking open) then clicking outside the popover…

In Chrome, the popover fades out in place.

In Safari, the popover changes position, then fades out.

Chrome's behaviour is achieving what I wanted in this case, but I'm pretty sure Safari is correct according to the spec.

The implicit anchor is removed straight after the "beforetoggle" event, which explains the Safari behaviour, whereas it seems to 'stick' in Chrome.

---

I'm not sure what the solution is here. Either the change to the implicit anchor element needs to delay in some way that just works, or maybe the developer needs to delay the change to this value, eg:

#mypopover {
  transition: position-anchor 1000ms ease allow-discrete;
}

[jakearchibald]

What would be the downside of only setting the implicit anchor element when the popover shows (including setting it to null if there's no source)?

[lukewarlow]

WebKit ties the popover "implicit anchor" to the "popover trigger" concept currently, so to make it only set to null during show would effectively require that be rewritten, just as an fyi.

I'm slightly confused why the spec is only setting "implicit anchor element" to null when fireEvents is true? That seems wrong?

[jakearchibald]

@lukewarlow I don't understand. What would happen if WebKit simply didn't null the "implicit anchor" on the close case.

[keithamus]

If I understand what Luke is saying, it is that WebKit doesn't store an implicit anchor and instead resolves it to the popover trigger, instead. From my perspective that seemed sensible, initially. Upon further investigation though it seems as though the implicit anchor steps are what cause reflow. How does WebKit handle reflow in this regard? Perhaps the issue is around reflow?

I'm slightly confused why the spec is only setting "implicit anchor element" to null when fireEvents is true? That seems wrong?

Looks like this is wrong. Chrome removes implicit anchor association during "remove from the top layer immediately". So it would make sense for it to be step 12, not 9.5.

[lukewarlow]

Yeah basically what Keith said.

WebKit doesn't store an "implicit anchor" explicitly. It has an "invoker" in PopoverData and an "invokedPopover" on Element. Implicit anchoring is keyed off of the "invokedPopover" part of Element which when updated triggers something in the style system.

[jakearchibald]

@keithamus

Chrome removes implicit anchor association during "remove from the top layer immediately". So it would make sense for it to be step 12, not 9.5.

That would still be too early for the codepen demo, right? It'd result in the Safari behaviour.

[jakearchibald]

If Chrome is only removing the association in cases where it's "removed from the top layer immediately", that seems ok. The spec should do the same, so 10.1?

[jakearchibald]

It seems like "removed from the top layer immediately" only happens if the popover attribute is removed. Maybe there are a couple of other edge cases.

Ugh that boolean shouldn't be called fireEvents since it's just one of the things it does.

[keithamus]

That would still be too early for the codepen demo, right? It'd result in the Safari behaviour.

It would if we're assuming that removing the implicit anchor association is what causes reflow. However given Chrome sets the implicit anchor association more closely aligned with the spec, I am guessing it has other logic to handle when reflow should occur for implicit anchors.

I wonder if it should be part of the css spec to talk about how reflowing an implicit anchor should be delayed if an animation or transition is occurring?

If Chrome is only removing the association in cases where it's "removed from the top layer immediately", that seems ok. The spec should do the same, so 10.1?

If it was in 10.1 it would also need to remain in 9.5. It could be step 12 (or 11) and handle for both if fireEvents is true, or false.

[lukewarlow]

Ahh I think I might know what it is, the spec is wrong.

"removed from the top layer immediately" actually gets called in both codepaths. Chrome sets implicit anchor element to null as part of those steps. Which are delayed in the case you "Request an element to be removed from the top layer"

I'm not sure WebKit actually has a distinction between these two cases, I guess because the overlay property isn't implemented outside of Chromium?

[keithamus]

Chrome has another logic; it has the maybe implicit anchor which, when set, causes reflow only if it's being added (not removed): https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/element.cc;drc=ce651b75de646270fc28ce175bcc951842095309;bpv=0;bpt=1;l=12428

IOW when an implicit anchor is removed, Chrome intentionally skips reflow, which is likely why you're not seeing the animation bug in Chrome. I imagine WebKit triggers style invalidation whenever it changes and so runs into the situation described in OP.

[jakearchibald]

I'm not 100% sure what 'reflow' means here, but ideally the popover should continue to position in relation to the button until it leaves the top layer.

[lukewarlow]

It leaves the top layer immediately though, because only Chromium actually supports the overlay property which is what keeps it in the top layer for a longer period of time. This might just be a symptom of that being missing?

https://searchfox.org/wubkat/source/Source/WebCore/html/HTMLElement.cpp#1230 - WebKit might actually be removing the implicit anchor too early regardless, I think this line needs moving down to 1245 too. But because there's no overlay the behaviour is the same.

[keithamus]

Reflow = Layout invalidation. Chrome skips invalidating the layout when removing an implicit anchor, so the anchored position association is no longer there but that fact is ignored because the style engine hasn't been told to update. If I had to guess, I'd imagine if you triggered reflow somehow, maybe by animating the width or setting the style attribute during animation, it would pop?