Intent to Ship: Close requests for CloseWatcher, <dialog>, and popover=""
Domenic Denicola
Contact emails
jap...@chromium.org, dom...@chromium.org, jar...@chromium.orgExplainer
https://github.com/WICG/close-watcher/blob/main/README.mdSpecification
https://github.com/whatwg/html/pull/9462Summary
"Close requests" are a new concept that encompasses user requests to close something currently open, using the Esc key on desktop or the back gesture/button on Android. Integrating them into Chromium comes with two changes: * CloseWatcher, a new API for directly listening and responding to close requests. * Upgrades to <dialog> and popover="" to use the new close request framework, so that they respond to the Android back button.
Blink component
BlinkTAG review
https://github.com/w3ctag/design-reviews/issues/594TAG review status
Issues addressedRisks
Interoperability and Compatibility
This API is designed to have an interoperable surface for web developers, to help them avoid platform-specific code. So, if it were implemented across browsers, it would be a positive for interoperability. Otherwise, it has the usual risks of not getting adopted by other vendors. Compatibility: To avoid allowing CloseWatchers, dialogs, and popovers ("close watchers") to prevent the Android back gesture/button from navigating through history, how close watchers respond to close requests depends on user activation. If no user activation occurs between opening, and the user issuing a close request, this can cause a CloseWatcher/dialog's cancel event to be skipped, or cause multiple close watchers to be closed at once. Although this behavior is meant to prevent back-trapping on Android specifically, it applies to desktop as well, for interoperability reasons. This change is a compatibility risk. However, use counters show it to be an acceptable one: - 0.000015% of pages impacted by skipped cancel events - 0.000007% of pages impacted by skipped cancel events that would otherwise call preventDefault() - between 0.000000% and 0.000001% of pages impacted by multiple dialogs closed
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/604)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/215)
Web developers: Positive (https://github.com/w3ctag/design-reviews/issues/594#issuecomment-890257686) See also https://bugs.chromium.org/p/chromium/issues/detail?id=1319915
Other signals:
Activation
The CloseWatcher API is meant to be usable as a progressive enhancement; if developers use it with feature detection, then their app will be able to watch for unusual close watchers in supporting browsers, while falling back to listening for the Esc key in browsers that haven't implemented the API. It would benefit from a conditional polyfill that translates the Esc key into a close signal, so that then developers don't even have to have feature detection and fallback logic, but can just use the CloseWatcher API surface. One such polyfill is available in the demo: https://close-watcher-demo.glitch.me/
Security
The main security-related concern in this API is preventing it from being usable for back-trapping, i.e. disabling the Android back gesture/button. Although this is already possible in Chromium and other browsers due to bugs, we worked to ensure CloseWatcher and close request integration to dialogs/popups does not increase the size of the problem, by gating repeated use of these behind transient user activation checks: see https://github.com/WICG/close-watcher#abuse-analysis
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
Beyond the low risks already listed in the Compat section, we do not anticipate any WebView-specific risks. A base::Feature killswitch is available just in case.
Debuggability
No special DevTools support is required.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name on chrome://flags
CloseWatcherFinch feature name
CloseWatcherRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1171318Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
No.Sample links
https://close-watcher-demo.glitch.me
Estimated milestones
| Shipping on desktop | 119 |
| DevTrial on desktop | 97 |
| Shipping on Android | 119 |
| DevTrial on Android | 97 |
| Shipping on WebView | 119 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None.Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4722261258928128Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/NA5NC16OmsU
Alex Russell
Domenic Denicola
The implicit behaviours based on construction order in this API are very strange and seem like footguns.
The TAG feedback didn't touch on this very much, AFAICT, but it's somewhat surprising that the stack of close actions isn't inspectable.
- We received no developer or partner feedback requesting this capability
- This could cause potential forward-compat problems without careful design. E.g., it could make it possible for developers to write code that assumes that only CloseWatchers, dialogs, and popover="" elements are close watchers, and thus make it hard for the web platform to introduce a fourth close watcher (e.g., <selectlist>) in the future.
- This would be somewhat of an encapsulation leak between different parts of the application, making it harder to write resilient components. (This is not a strong argument, but rather a bias toward waiting for a use case instead of just exposing the information automatically.)
What's the behaviour of non-`destroy()`'d watchers; e.g. if a developer forgets to dispose of one correctly? Can users get stuck?
On Wednesday, September 27, 2023 at 7:43:49 PM UTC-7 Domenic Denicola wrote:
Alex Russell
On Sat, Sep 30, 2023 at 5:01 AM Alex Russell <sligh...@chromium.org> wrote:The implicit behaviours based on construction order in this API are very strange and seem like footguns.I don't understand why you find this strange, or a footgun. It's intended to be the opposite: it guides developers toward creating the experience the user expects, where when the user requests to close something, the last thing that was opened, is what closes.
https://noncombatant.org/2023/05/29/complexities-of-allocation/
The TAG feedback didn't touch on this very much, AFAICT, but it's somewhat surprising that the stack of close actions isn't inspectable.I can't speak for the TAG, but here are the reasons why the stack of close watchers isn't inspectable:
- We received no developer or partner feedback requesting this capability
- This could cause potential forward-compat problems without careful design. E.g., it could make it possible for developers to write code that assumes that only CloseWatchers, dialogs, and popover="" elements are close watchers, and thus make it hard for the web platform to introduce a fourth close watcher (e.g., <selectlist>) in the future.
- This would be somewhat of an encapsulation leak between different parts of the application, making it harder to write resilient components. (This is not a strong argument, but rather a bias toward waiting for a use case instead of just exposing the information automatically.)
What's the behaviour of non-`destroy()`'d watchers; e.g. if a developer forgets to dispose of one correctly? Can users get stuck?Non-destroy()ed is the default state of a CloseWatcher, so such CloseWatchers will respond to the next close request if they are on the top of the stack. The user cannot really get stuck, as every close request will either destroy the topmost close watcher on the stack, or possibly trigger (at most once) a preventDefault()ed cancel event. See https://github.com/WICG/close-watcher/blob/main/README.md#abuse-analysis for more details.
Note that the API generally guides you away from this possibility by making the simpler code be the one that automatically calls destroy() for you: https://github.com/WICG/close-watcher/blob/main/README.md#requesting-close-yourself .
On Wednesday, September 27, 2023 at 7:43:49 PM UTC-7 Domenic Denicola wrote:
Contact emailsjap...@chromium.org, domenic@chromium.org, jarhar@chromium.org
Explainerhttps://github.com/WICG/close-watcher/blob/main/README.md
Specificationhttps://github.com/whatwg/html/pull/9462
Summary"Close requests" are a new concept that encompasses user requests to close something currently open, using the Esc key on desktop or the back gesture/button on Android. Integrating them into Chromium comes with two changes: * CloseWatcher, a new API for directly listening and responding to close requests. * Upgrades to <dialog> and popover="" to use the new close request framework, so that they respond to the Android back button.
Blink componentBlink
TAG reviewhttps://github.com/w3ctag/design-reviews/issues/594
TAG review statusIssues addressed
Risks
Interoperability and CompatibilityThis API is designed to have an interoperable surface for web developers, to help them avoid platform-specific code. So, if it were implemented across browsers, it would be a positive for interoperability. Otherwise, it has the usual risks of not getting adopted by other vendors. Compatibility: To avoid allowing CloseWatchers, dialogs, and popovers ("close watchers") to prevent the Android back gesture/button from navigating through history, how close watchers respond to close requests depends on user activation. If no user activation occurs between opening, and the user issuing a close request, this can cause a CloseWatcher/dialog's cancel event to be skipped, or cause multiple close watchers to be closed at once. Although this behavior is meant to prevent back-trapping on Android specifically, it applies to desktop as well, for interoperability reasons. This change is a compatibility risk. However, use counters show it to be an acceptable one: - 0.000015% of pages impacted by skipped cancel events - 0.000007% of pages impacted by skipped cancel events that would otherwise call preventDefault() - between 0.000000% and 0.000001% of pages impacted by multiple dialogs closed
Gecko: Positive (https://github.com/mozilla/standards-positions/issues/604)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/215)
Web developers: Positive (https://github.com/w3ctag/design-reviews/issues/594#issuecomment-890257686) See also https://bugs.chromium.org/p/chromium/issues/detail?id=1319915
Other signals:
ActivationThe CloseWatcher API is meant to be usable as a progressive enhancement; if developers use it with feature detection, then their app will be able to watch for unusual close watchers in supporting browsers, while falling back to listening for the Esc key in browsers that haven't implemented the API. It would benefit from a conditional polyfill that translates the Esc key into a close signal, so that then developers don't even have to have feature detection and fallback logic, but can just use the CloseWatcher API surface. One such polyfill is available in the demo: https://close-watcher-demo.glitch.me/
SecurityThe main security-related concern in this API is preventing it from being usable for back-trapping, i.e. disabling the Android back gesture/button. Although this is already possible in Chromium and other browsers due to bugs, we worked to ensure CloseWatcher and close request integration to dialogs/popups does not increase the size of the problem, by gating repeated use of these behind transient user activation checks: see https://github.com/WICG/close-watcher#abuse-analysis
WebView application risksDoes this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
Beyond the low risks already listed in the Compat section, we do not anticipate any WebView-specific risks. A base::Feature killswitch is available just in case.
DebuggabilityNo special DevTools support is required.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
Is this feature fully tested by web-platform-tests?Yes
Flag name on chrome://flagsCloseWatcher
Finch feature nameCloseWatcher
Requires code in //chrome?False
Non-OSS dependenciesDoes the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?
No.
Sample links
https://close-watcher-demo.glitch.me
Estimated milestonesShipping on desktop119DevTrial on desktop97Shipping on Android119DevTrial on Android97Shipping on WebView119
Anticipated spec changesOpen questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/4722261258928128
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/NA5NC16OmsU
Domenic Denicola
On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:On Sat, Sep 30, 2023 at 5:01 AM Alex Russell <sligh...@chromium.org> wrote:The implicit behaviours based on construction order in this API are very strange and seem like footguns.I don't understand why you find this strange, or a footgun. It's intended to be the opposite: it guides developers toward creating the experience the user expects, where when the user requests to close something, the last thing that was opened, is what closes.Chris Palmer covered this pretty well recently, so I'll defer to his more eloquent writeup:
https://noncombatant.org/2023/05/29/complexities-of-allocation/Basically, this is spooky action at a distance and without _at least_ some reflection and manipulation surface (via DOM, probably), it's hard to understand how this won't turn into a footgun.As a separate note, I'm disappointed in the proliferation of APIs that affect DOM but have no API and reflection. Import Maps spring to mind, but there are other recent examples too. If manual disposal is going to be required for this, we should at least make it possible to introspect outside the scope in which an object that defines this behaviour is allocated.
Alex Russell
On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:On Sat, Sep 30, 2023 at 5:01 AM Alex Russell <sligh...@chromium.org> wrote:The implicit behaviours based on construction order in this API are very strange and seem like footguns.I don't understand why you find this strange, or a footgun. It's intended to be the opposite: it guides developers toward creating the experience the user expects, where when the user requests to close something, the last thing that was opened, is what closes.Chris Palmer covered this pretty well recently, so I'll defer to his more eloquent writeup:
https://noncombatant.org/2023/05/29/complexities-of-allocation/Basically, this is spooky action at a distance and without _at least_ some reflection and manipulation surface (via DOM, probably), it's hard to understand how this won't turn into a footgun.As a separate note, I'm disappointed in the proliferation of APIs that affect DOM but have no API and reflection. Import Maps spring to mind, but there are other recent examples too. If manual disposal is going to be required for this, we should at least make it possible to introspect outside the scope in which an object that defines this behaviour is allocated.In what way does this API affect the DOM? No parts of the DOM tree are modified by CloseWatcher. The same is true for import maps...
Domenic Denicola
On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote:On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:On Sat, Sep 30, 2023 at 5:01 AM Alex Russell <sligh...@chromium.org> wrote:The implicit behaviours based on construction order in this API are very strange and seem like footguns.I don't understand why you find this strange, or a footgun. It's intended to be the opposite: it guides developers toward creating the experience the user expects, where when the user requests to close something, the last thing that was opened, is what closes.Chris Palmer covered this pretty well recently, so I'll defer to his more eloquent writeup:
https://noncombatant.org/2023/05/29/complexities-of-allocation/Basically, this is spooky action at a distance and without _at least_ some reflection and manipulation surface (via DOM, probably), it's hard to understand how this won't turn into a footgun.As a separate note, I'm disappointed in the proliferation of APIs that affect DOM but have no API and reflection. Import Maps spring to mind, but there are other recent examples too. If manual disposal is going to be required for this, we should at least make it possible to introspect outside the scope in which an object that defines this behaviour is allocated.In what way does this API affect the DOM? No parts of the DOM tree are modified by CloseWatcher. The same is true for import maps...This is view state, which is frequently reflected via DOM. The primary concern here is that there's no way to inspect and/or modify the stack (attached to Node instances or not) independently of closure-scoped object lifetimes.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-SULEU6D-HmDDuf%3D5T9faNVk_LcqjKxY%3Do%3Du-vqTzaag%40mail.gmail.com.
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Domenic Denicola
Philip Jägenstedt
Yoav Weiss
Domenic Denicola
- A bug fix to allow cancel events to fire for the first-created close watcher, as long as it was created by user activation. Even if the user never interacts with the <dialog>. Spec issue, spec PR, wip CL.
- A more significant change, to consider firing cancel events even if you cannot call preventDefault(). Spec issue.