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.
