Close requests and close watchers

[domenic]

WebKittens

@annevk and @othermaciej have both previously reviewed this

Title of the spec

Close signals and close watchers

URL to the spec

https://html.spec.whatwg.org/multipage/interaction.html#close-requests-and-close-watchers

URL to the spec's repository

https://github.com/WICG/close-watcher

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

w3ctag/design-reviews#594

Mozilla standards-positions issue URL

mozilla/standards-positions#604

WebKit Bugzilla URL

No response

Radar URL

No response

Description

In addition to the WICG repository with the explainer, see the HTML Standard pull request: whatwg/html#9462

The main new API introduced here is the CloseWatcher API. But this spec also includes changes to unify dialog, popover, and fullscreen handling into a single "close watcher" concept, which is triggered by a platform-independent concept of "close request".

For macOS and keyboard-attached iOS devices, the close request would be the Esc key. For other iOS devices, there might not be a close request. This was previously discussed in WICG/close-watcher#11 ; see also https://github.com/WICG/close-watcher/blob/main/platform-implementation-notes.md . In such cases, it would still be ideal for the API to exist and be implemented, and just never triggered via user action, so that developers can write platform-agnostic code (e.g. centralizing their close logic into the close event handler of a CloseWatcher object).

Because of how close request gestures can serve multiple purposes, e.g. the Android back button/gesture being used to navigate session history, the specification has some anti-abuse measures to prevent the close signal gesture from being indefinitely captured by web developers using dialogs, popovers, or CloseWatchers. These measures might not be necessary in the macOS/iOS-with-keyboard ecosystem, where the Esc key is the only relevant gesture and it does not serve another purpose. But we think they're still reasonable, and should be implemented uniformly across platforms for interoperability. This was previously discussed from one angle in WICG/close-watcher#10.

[annevk]

Is there an explanation somewhere as to why Android cannot synthesize Esc key events to simulate the existing convention for close requests on other platforms? At least from a distance this seems like a lot of new functionality for a feature that essentially already exists.

[domenic]

Yes: https://github.com/WICG/close-watcher#automatically-translating-all-close-requests-to-esc

[lukewarlow]

Chrome intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/jM5au7yYzHM/m/L8r7x5CmAAAJ

[lukewarlow]

Just as an fyi this has been merged into the html spec and shipped in chromium 120

[lukewarlow]

This has gone through some iteration in the spec and chrome implementation to handle some edge cases better. As a result it should be even more stable to implement in WebKit. It would be good to get an official signal of support or feedback on possible changes to achieve that, (especially as it's currently unshipped in chrome while it went through some of these changes)

[annevk]

Colleagues and I looked at this again and are still not entirely convinced it's worth the complexity given that for Apple platforms at least this is essentially what the Esc key is for. Something centered around that would have been more palatable. However, as we do see the need for some API in this space and the main downside of CloseWatcher is its verbosity we suggest closing this with "position: neutral" one week from now.

[lukewarlow]

@domenic could you update the URL to point to the actual spec at https://html.spec.whatwg.org/multipage/interaction.html#close-requests-and-close-watchers and the URL repo link to point to the html spec? Else the links on webkit.org will end up being outdated.

[annevk]

I updated the URL. The repository still seems accurate? It's not archived anyway.

Will update webkit.org later.