The spec change has now landed, LGTM2. More introspection could possibly be useful <https://github.com/whatwg/html/pull/9462#discussion_r1361110313>, but without a concrete use case, example code, or developer feedback, I think it's hard to do a good job. Having reviewed the spec change, I'm confident that exposing more information is technically straightforward if the need arises.
On Thu, Oct 12, 2023 at 1:59 AM Domenic Denicola <dome...@chromium.org> wrote: > > > On Thu, Oct 12, 2023 at 12:51 AM Yoav Weiss <yoavwe...@chromium.org> > wrote: > >> >> >> On Friday, October 6, 2023 at 12:34:21 AM UTC+2 Chris Harrelson wrote: >> >> Hi, >> >> While Alex's concerns are totally valid to consider from a feature design >> perspective, I think they are better to be discussed on the WHATWG issues >> for this feature. I chatted offline with Alex and he agreed about that >> point, and agreed to post comments and questions there. >> >> So from an API owners perspective LGTM1 modulo considering and taking >> into account all comments and feedback from Alex on the spec (as we should >> for all such feedback from anyone, of course!). >> >> >> On Wed, Oct 4, 2023 at 8:28 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >> >> >> 2023年10月4日(水) 8:16 Alex Russell <slightly...@chromium.org>: >> >> >> >> On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote: >> >> >> >> 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... >> >> >> 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. >> >> >> It's not clear to me what definition of "view state" you are using, such >> that it encompasses things like the module specifier resolution algorithm >> or the routing of Android back gestures. >> >> Maybe, if this is a principle you believe in, you could file it as a >> suggestion on the w3ctag/design-principles repository, ideally with a clear >> explanation of what the boundaries of this "view state" concept are. >> (Including what, in your view, would *not* quality as view state.) >> >> >> >> 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 >> >> >> What's preventing the PR from landing? >> > > It needs review, and none of the other editors have made the time yet. > (Maybe +Philip Jägenstedt <foo...@chromium.org> could help?) > > >> >> >> >> >> 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/st >> andards-positions/issues/604) >> >> *WebKit*: No signal (https://github.com/WebKit/sta >> ndards-positions/issues/215) >> >> *Web developers*: Positive (https://github.com/w3ctag/des >> ign-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-SULEU6D-HmDDuf% >> 3D5T9faNVk_LcqjKxY%3Do%3Du-vqTzaag%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-SULEU6D-HmDDuf%3D5T9faNVk_LcqjKxY%3Do%3Du-vqTzaag%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/CAARdPYct9uaF8G%2By_qTZHZd5cu45kGudWNV%2BXG50pxP4Jp1nEg%40mail.gmail.com.
