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/CAM0wra8QEKxyWhmmWGdrHrchYjWrPtFgYWYt8YU44-G_s5Cy0w%40mail.gmail.com.
