Should hide popover algorithm always restore the previously focused element?

[nt1m]

According to https://html.spec.whatwg.org/#hide-popover-algorithm , the answer is yes.

According to WPT/Chrome's implementation, the answer is no. The previously focused element should be restored only when focus is currently in the popover. (This behavior does seem to make sense to me fwiw)

[nt1m]

cc @rwlbuis @josepharhar @mfreed7

[nt1m]

Fwiw, the original Chromium commit is at: https://chromium-review.googlesource.com/c/chromium/src/+/4322607

Not sure if contains() takes in account shadow DOM trees (it might, I'm not sure).

[Yay295]

The previously focused element should be restored only when focus is currently in the popover.

I suppose this is to allow you to set the focus to something while the popover is open? I think there was another issue in this repository about doing that, but I don't remember if it came to a conclusion.

[mfreed7]

According to https://html.spec.whatwg.org/#hide-popover-algorithm , the answer is yes.

According to WPT/Chrome's implementation, the answer is no. The previously focused element should be restored only when focus is currently in the popover. (This behavior does seem to make sense to me fwiw)

We discussed this to get to the current behavior in Chromium, which I do think is better. The problem case without this special casing is that the user opens a popover, then tab-navigates somewhere else and activates another button. That light dismisses the popover, but feels very odd for the focus to suddenly shift back to the popover activating button. It feels natural if the focus is still within the popover, since it has to go somewhere from there now that the popover is closing.

Sorry - I thought we had also put up a spec PR to discuss this change. @josepharhar do you know if there's a PR somewhere for this?

[nt1m]

Ah looks like there was a PR put up a month ago about this: #9018 and I forgot. Sorry