Contact emailsjap...@chromium.org, dome...@chromium.org, jar...@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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/594 TAG review statusIssues addressed Risks 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)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes Flag name on chrome://flagsCloseWatcher Finch feature nameCloseWatcher Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1171318 Non-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/4722261258928128 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/NA5NC16OmsU This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8ZW1%3DUa8MkteUNpXvTdX8SGxaxRLQqQP8jYbTe9vD36w%40mail.gmail.com.
