Add close requests and close watchers

[domenic]

This adds the generic close request concept, which allows interfaces like the Esc key, or back gestures and buttons, to be interpreted as closing various "close watchers". Two existing constructs are converted to close watchers: modal dialog elements, and auto popovers. Additionally, this adds the CloseWatcher API, which lets web developers create their own close watchers. Note that the close request steps formalize previously-informal parts of the Fullscreen API Standard.

The specification text here is largely ported from https://github.com/WICG/close-watcher/blob/3a18e6811528d349df27a3e7b06b8dc018638c4c/spec.bs. Updates include:

• Requiring keyup to be the close request event for user agents which use the Esc key as a close request, per discussions in popover light dismiss behavior is not specified for Esc key #9143.
• Introducing requestClose(), per close() should not trigger cancel, at least by default WICG/close-watcher#28.
• Renaming the "close signal" concept to "close request".

This change to dialog behavior is a potential compatibility risk, especially since it can cause the cancel event to be skipped if there has been no user activation since the last time it was canceled, or multiple dialogs to be closed at once. However, Chromium data shows these risks to be negligible:

• https://chromestatus.com/metrics/feature/timeline/popularity/4422 shows 0.000015% of pages impacted by skipped cancel events
• https://chromestatus.com/metrics/feature/timeline/popularity/4423 shows 0.000007% of pages impacted by skipped cancel events that would otherwise call preventDefault()
• https://chromestatus.com/metrics/feature/timeline/popularity/4424 shows between 0.000000% and 0.000001% of pages impacted by multiple dialogs closed

Closes #9143. Closes #5667.

• At least two implementers are interested (and none opposed):
  • Chromium
  • Mozilla
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/close-watcher
• Implementation bugs are filed:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1171318
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1859702
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=263305
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• MDN issue is filed: Document close watchers, close requests, and the CloseWatcher API mdn/mdn#463

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/browsers.html ( diff )
/dnd.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )

[mbrodesser-Igalia]

The examples and notes are illuminating, thanks.

[mbrodesser-Igalia]

Reviewed https://whatpr.org/html/9462/c3ca6c2...01ef747/popover.html and those changes look correct.
Reviewed https://whatpr.org/html/9462/interaction.html#close-signal-steps thoroughly but not exhaustively and at least the requirement (signaling close on keyup event when tapping the Esc key) is fulfilled. Didn't review the tests.

[mbrodesser-Igalia]

In general the changes seem to be a strong improvement towards cross-platform compatibility.

[mbrodesser-Igalia]

Concerning tests for the popover attribute: there's already https://searchfox.org/mozilla-central/rev/7907fd85f6fd1cee3acaddbaf27a76b23d6d9993/testing/web-platform/tests/html/semantics/popovers/popover-change-type.html.

However, it's still concerning that the behavior is only specified for the Escape key, and it's implementation defined for other events. Consequently, WPT-coverage will have gaps on e.g. mobile platforms. That's problematic and I don't have solution for it. If that problem has been considered, thoughts about it would be appreciated.

[josepharhar]

Thanks for writing all this!
I created a chromium patch to implement the missing popover integration: https://chromium-review.googlesource.com/c/chromium/src/+/4686066

[josepharhar]

Instead of putting this in cleanupSteps/cleanupHidingFlag, can't we just destroy the closewatcher at the very end of the hide popover algorithm?

[domenic]

Then the close watcher won't be destroyed in the invalid cases, right? Hmm. I think that would be wrong. For example, if "hide all popovers until" or firing beforetoggle caused the popover to get disconnected from the document, or become a modal dialog, then we should probably destroy the popover close watcher. Right?

[josepharhar]

I think that the only way that beforetoggle can make hide popover abort is if beforetoggle caused a nested call to hide popover.
If it gets disconnected, then hide popover will get called again and successfully hide the popover and reach the end of the algorithm, where we would destroy the closewatcher.
beforetoggle and other stuff can't turn it into a modal dialog, because the show modal steps will throw an exception if it is an open popover.
Can you think of any other cases? If so I can write a test for it

[domenic]

I can't think of any other cases. But now I'm confused about what the point of cleanupSteps is. Why can't we move "If nestedHide is false, then set element's popover showing or hiding to false." down to the bottom as well?

In other words, I'm confused why the logic for setting that flag to false, doesn't apply to close watcher destruction. What is different about those two? (Almost certainly there is something different and I just am not familiar enough with popover to understand.)

[josepharhar]

In the case that beforetoggle causes hide popover to abort by causing a nested call to hide popover, we will reach the end of hide popover for this popover once. However, each of the two hide popover calls will have a different value for nestedHide that they each want to set when they return from the algorithm. We need the first, not nested call to set popover or showing or hiding to false whenever it returns - I suppose that the nested call could also set it to false and that might be OK.

This nestedHide/cleanupSteps/popover showing or hiding machinery was my translation of a stack-scoped variable that was implemented in chromium, and it certainly looks very clean in C++. I suppose that there may be a simpler way to write this in spec code.

In the meantime, I guess its fine to put it in either cleanupSteps or the end of hide popover.

[domenic]

Thanks so much for the review and help Joey!!

[domenic]

Then the close watcher won't be destroyed in the invalid cases, right? Hmm. I think that would be wrong. For example, if "hide all popovers until" or firing beforetoggle caused the popover to get disconnected from the document, or become a modal dialog, then we should probably destroy the popover close watcher. Right?

[foolip]

If getting the free slot is important, a way to inspect whether one will get it or did get it could be useful. It could be a boolean getter that depends on "was created with user activation" and "is grouped with previous", or it could be by exposing the close watcher stack, and checking if its size is 1. I don't suggest any of the changes now, just making an observation.

[domenic]

I agree, it seems like the kind of thing that could in theory be useful. However, I was unable to figure out what kind of application code might use it, and I didn't hear any requests from developers yet. So, I've punted this sort of introspection stuff.

[foolip]

The "everything in a task" rewrite is a big improvement, thanks @domenic!