popover light dismiss behavior is not specified for Esc key

[asurkov]

The light dismiss paragraph mentions Esc key behavior used for auto popover light dismiss, but apparently it's not specified anywhere, see https://html.spec.whatwg.org/multipage/popover.html#popover-light-dismiss.

I suppose it should be simple as listen for keypress trusted event on a document and if Esc key was pressed and topmost auto popover is not null, then close it.

[emilio]

We should clearly define when this is supposed to happen, since it can run script... Curious, what does Chromium do @mfreed7 @josepharhar

[josepharhar]

This text currently specifies how it works:

user agents may provide a user interface that, upon activation, queues an element task on the user interaction task source given topmost auto popover to run the hide popover algorithm

I wrote it this way because I was copying the dialog element, which says the same thing:

user agents may provide a user interface that, upon activation, queues an element task on the user interaction task source given the dialog element to run these steps:

We should clearly define when this is supposed to happen, since it can run script

I totally agree. If CloseWatcher gets specced then it might be able to replace the existing text on its own and specify when this is supposed to happen, but I'm not opposed to improving the spec now without CloseWatcher.

Curious, what does Chromium do

If any node's default event handler sees a keydown event for the escape key and the event's target is the node, then chromium will close the active modal dialog if there is one and run popover light dismiss. I assume that default event handlers are well specified. Here is exactly where this occurs.

[asurkov]

This text currently specifies how it works:

user agents may provide a user interface that, upon activation, queues an element task on the user interaction task source given topmost auto popover to run the hide popover algorithm

I wrote it this way because I was copying the dialog element, which says the same thing:

If any node's default event handler sees a keydown event for the escape key and the event's target is the node, then chromium will close the active modal dialog if there is one and run popover light dismiss. I assume that default event handlers are well specified. Here is exactly where this occurs.

Would the spec benefit from providing the exact algorithm for Esc key handling similar to pointerup/down events algorithm? For example, it seems nothing indicates now that it has to be a keydown event.

[josepharhar]

Would the spec benefit from providing the exact algorithm for Esc key handling similar to pointerup/down events algorithm? For example, it seems nothing indicates now that it has to be a keydown event.

Yes, I believe it would benefit

[emilio]

For the record native popups in Gecko also use keydown, though we add a regular event listener to the document.

cc @smaug----

[jakearchibald]

I don't think it should queue a task. light dismiss open popovers doesn't queue a task.

[nt1m]

It would be nice to specify the precedence between active modal dialog, topmost auto popover and fullscreen element.

[domenic]

I think the right starting point for any spec here is https://wicg.github.io/close-watcher/#close-signals , which we could move into HTML at any time. (And get more review on it, as part of that move.)

Some notable choices made in that spec, which we could discuss:

• Un-fullscreening is always top priority, and doing so stops any key events from being fired. This matches browser behavior in the tests that I ran.
• The exact choice of what event triggers a close signal is left up to the user agent. E.g. Esc keydown on desktops, but maybe a swipe-up on iOS, back gesture on Android, etc.
• User agents are allowed to let canceling the related event prevent the close signal. (E.g., on desktop, canceling the keydown event prevents the close signal.)
• After that, close watchers react in a stack-like manner: most-recently-pushed triggers first.
  • Currently in that document, there are two types of close watchers: <dialog>, and the new CloseWatcher API.
  • If we moved the spec into HTML, we could start with <dialog> + popover="". In a separate future PR we could talk about adding CloseWatcher.
• Close watchers in that document have some complicated stuff around user activation, to prevent you from creating tons of close watchers with no user activation, and then using this to back-trap the user. See some discussion at https://github.com/WICG/close-watcher#asking-for-confirmation and following sections. This might be controversial and could be left to a follow-up PR. (Although the latest use counters from Chromium imply that it should be easy to ship with no compat issues.)

[domenic]

We discussed this a bit in the triage meeting (https://github.com/whatwg/html/issues/9132). Points that came up:

• @emilio would prefer more mandatory interop / less user agent freedom than the Close Watcher spec provides, for example requiring keydown to be used for Esc key presses instead of allowing a choice of event. From the perspective of CloseWatcher, Chromium is fine with this; if @mfreed7 or @josepharhar disagree from the perspective of popover="", please let us know.

• @emilio will help suggest ways of making the linked section of the close watcher spec more rigorous, and once we have that, @domenic will work on integrating it into HTML.

• @emilio suggested he wasn't sure about the Android back button closing all modal <dialog>s. We didn't get into this in detail. My additional perspective on this: we're not 100% sure from the Chromium side, but we want to try shipping it, because we think it's the right thing to do. Maybe this indicates our initial HTML spec PR should just include popover="" as a close watcher, leaving <dialog> for the hopeful future in which Chromium has shipped and proven it compatible with developer and user expectations.

[josepharhar]

if @mfreed7 or @josepharhar disagree from the perspective of popover="", please let us know.

This is fine. If we end up changing the chromium behavior, then I'll just do it behind a flag and may push back if it breaks any websites but I don't imagine thats likely.

[mfreed7]

• @emilio would prefer more mandatory interop / less user agent freedom than the Close Watcher spec provides, for example requiring keydown to be used for Esc key presses instead of allowing a choice of event. From the perspective of CloseWatcher, Chromium is fine with this; if @mfreed7 or @josepharhar disagree from the perspective of popover="", please let us know.

Yeah, I think this is ok too.

It would be nice to specify the precedence between active modal dialog, topmost auto popover and fullscreen element.

I just wanted to highlight this comment - I agree. I think the intention is that fullscreen always takes precedence, but there are open questions such as what happens if there are nested elements? For example, a fullscreen element contains an open popover. When Esc de-fullscreens the element, should it also close the popover?

I made a WPT for at least the basics of non-nested top layer elements, to verify which things close which things:

https://wpt.fyi/results/html/semantics/popovers/popover-top-layer-interactions.html?label=master&label=experimental&aligned

The Popover spec PR and that WPT basically just verify that everything closes popovers. But it doesn't clarify the other interactions, such as modal dialog and fullscreen.

[mbrodesser-Igalia]

I don't think it should queue a task. light dismiss open popovers doesn't queue a task.

@jakearchibald why shouldn't it queue a task? If that's agreed upon, it would be helpful to update the HTML spec (https://html.spec.whatwg.org/multipage/popover.html#popover-light-dismiss).

Even if above question was answered, the current spec wouldn't be precise enough to provide interoperable implementations.

[domenic]

I've put up #9462, which as part of porting over the close signal infrastructure, attempts to address this. I'd love reviews of that from folks. The relevant parts are at https://whatpr.org/html/9462/interaction.html#close-signal-steps .