LGTM1. This seems like a valuable movement toward interop on tricky edge-cases, and the team has done a good job with use counters and beta experiments to bound the compat risks. I think Finch can be used as a killswitch if we find that this has some horrible breaking impact that has not yet been discovered.
One path toward gaining even more confidence here would be to investigate individual sites. You could use either UKM or HTTP archive analysis to find sites where the upper-bound use counter fires, and then manually try to play around with them both with and without the flag to see if anything is broken. To move everyone toward interop, I suggest commenting on https://bugzilla.mozilla.org/show_bug.cgi?id=1885232 to encourage Firefox to fast-follow, and maybe filing a WebKit bug for the same reason. On Thu, Feb 6, 2025 at 6:22 AM Mustaq Ahmed <mus...@chromium.org> wrote: > Hi Mike and Yoav: > > Let me answer your questions together: > > *Current behavior in major browsers:* The click target is: > - [Chrome] the common ancestor of pointerdown target and *captured* > pointerup target. > - [Firefox] the actual pointerup target, ignoring capture and pointerdown. > - [Safari] the common ancestor of pointerdown target and actual pointerup > target, ignoring capture. > > *Compat risk analysis:* > - Our UseCounter shows that ~0.1% of Chrome page loads have (a) click > handlers at both the common ancestor and the capture target, and (b) this > feature would switch the click target from the former to the latter. This > seems like a loose upper bound because the two handlers could be doing the > same job. > https://chromestatus.com/metrics/feature/timeline/popularity/3942 > - We have the feature enabled on Canary & Dev for 7 weeks and on Beta for > 3 weeks, and we didn't see any bug reports. > > *Developers possibly capturing to a "wrong" element:* > IMHO it is hard to be "wrong" here, let me explain why. Developers use > capturing mostly for a custom drag experience, like the slider mentioned in > the intent or a map widget, and "click" is not an expected UI action after > such a drag. It seems impossible to know how often developers expect > clicks here, if at all. If any developers do expect clicks, they have to > resort to a hack (like adding one listener to multiple targets) because the > click-target inconsistencies among major browsers today left no "right" way > to capture a click! Did it answer your question @Yoav Weiss > <yoavwe...@chromium.org>? > > > > On Wed, Feb 5, 2025 at 11:32 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Wed, Feb 5, 2025 at 4:11 PM Mustaq Ahmed <mus...@chromium.org> wrote: >> >>> Contact emailsmus...@chromium.org >>> >>> Explainerhttps://w3c.github.io/pointerevents/#event-dispatch >>> >>> Specificationhttps://w3c.github.io/pointerevents/#event-dispatch >>> >>> Summary >>> >>> If a pointer is captured while the `pointerup` event is being >>> dispatched, the `click` event will be dispatched to the captured target >>> instead of the nearest common ancestor of `pointerdown` and `pointerup` >>> events as per the UI Event spec. For uncaptured pointers, the `click` >>> target remains unchanged. >>> >>> >>> Blink componentBlink>Input >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EInput%22> >>> >>> TAG reviewNone >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> Interop risk: No risk at all because the major browsers behaved >>> differently for years (see >>> https://github.com/w3c/pointerevents/issues/356#issuecomment-811814819). >>> Compat risk: There is a slight risk that the click target change would be >>> noticed for a very narrow case of a slider-like UI element that captures >>> the pointer yet expects a *container* element to respond to a click >>> differently from how the slider element itself responds to the same click. >>> For a drag action that starts on the slider and ends outside the slider, >>> this feature would cause the click event to be dispatched to the slider >>> then bubble up to the container (vs being dispatched to the container >>> element directly). >>> >> >> Have we tried to quantify the compat risk here? >> How often do we expect developers to capture the "wrong" element from >> their perspective? >> >> >>> >>> >>> *Gecko*: Positive ( >>> https://github.com/w3c/pointerevents/issues/356#issuecomment-1596196064) >>> >>> *WebKit*: No signal >>> >>> *Web developers*: Positive ( >>> https://github.com/w3c/pointerevents/issues/356#issuecomment-1591894867) >>> >>> *Other signals*: >>> >>> 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? >>> >>> None >>> >>> >>> Debuggability >>> >>> None >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, 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 >>> >>> >>> https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=pointerevents%2Fpointerevent_click_during_capture.html >>> >>> >>> Flag name on about://flagsNone >>> >>> Finch feature nameClickToCapturedPointer >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/40851596 >>> >>> Sample links >>> https://codepen.io/mustaqahmed/full/YzawKWW >>> >>> Estimated milestones >>> Shipping on desktop 135 >>> Shipping on Android 135 >>> Shipping on WebView 135 >>> >>> 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/5143357002874880?gate=5069716701577216 >>> >>> 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 visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5WP0%3DEV2%3DiQkS2Bkt8z4fKnfMFNBNeBEU76xOSsYNCHA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5WP0%3DEV2%3DiQkS2Bkt8z4fKnfMFNBNeBEU76xOSsYNCHA%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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4kZU5RxQiMGhMZqkDdPqGsdZLUd11bFY5xbyoizvFkhQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4kZU5RxQiMGhMZqkDdPqGsdZLUd11bFY5xbyoizvFkhQ%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9fV4Xhc%3Dqu%3D3Y%2BPaAoGebDw0eXZfL%3D_HwufOJmvJUDXg%40mail.gmail.com.
