2023年10月2日(月) 10:11 Alex Russell <slightly...@chromium.org>: > > > 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 <slightly...@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... > > > 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.) > > Thanks, I appreciate the context, and I am impressed by the thoroughness > of the design artifacts. > > > 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. > > > Also helpful; thank you! > > > 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, dome...@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 > <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 milestonesShipping on desktop119DevTrial on desktop97Shipping > on Android119DevTrial on Android97Shipping on WebView119 > > 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 Statushttps://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/CAM0wra_HYVps%3D%2Bt_6-iz%2BY7P%3D8fUw_ZSN7YmK4ftPJo5xY8YHg%40mail.gmail.com.
