Ok, thank you - glad to hear it's unrelated to tap. This seems almost bugfix-level to me then, unlikely to be a compat problem in practice despite the somewhat surprisingly large use of setPointerCapture.
Rick On Wed, Feb 12, 2025 at 3:17 PM Mustaq Ahmed <mus...@chromium.org> wrote: > This feature and the UseCounter stats mentioned above are for mouse clicks > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/input/mouse_event_manager.cc;drc=371045818e8ecd3f8e60ee58c1c23e0bd0b7f39f;l=358> > only. > So GestureTap clicks are not a concern at the moment. However, this makes > your setPointerCapture question difficult to answer! In fact we > were surprised to see setPointerCapture being used in at least 0.1% page > loads ("at least" because our UseCounter has other conditions to meet)!! > > > On Wed, Feb 12, 2025 at 10:54 AM Rick Byers <rby...@chromium.org> wrote: > >> LGTM3 >> >> I was surprised the UseCounter was so high, is that because this includes >> the implicit capture case for touch input? Or is setPointerCapture really >> that common? If it includes the touch implicit capture case, does that mean >> the click generated from a GestureTap can also have it's target changed? If >> so I'm worried about the web compat impact (eg. for code only run in >> Chromium like in Android WebView). But regardless it's reasonable to think >> of this as a bugfix for some niche poorly-defined behavior that likely >> won't matter to anyone, so I'm fine with giving it a try with the slow >> roll-out plan and emergency kill switch if real breakage is reported. >> >> Rick >> >> >> On Tue, Feb 11, 2025 at 1:53 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> LGTM2 >>> >>> On Sun, Feb 9, 2025 at 7:56 PM Domenic Denicola <dome...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Sat, Feb 8, 2025 at 5:29 AM Mustaq Ahmed <mus...@chromium.org> >>>> wrote: >>>> >>>>> My i2s message missed one important point: we are planning for an >>>>> incremental rollout on Stable, just to be on the safe side from the compat >>>>> perspective (see my WIP finch config cl/721367851 >>>>> <https://critique.corp.google.com/#review/721367851>, sorry internal >>>>> link). >>>>> >>>>> > 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. >>>>> >>>>> @Domenic Denicola <dome...@chromium.org> Perhaps we can defer this >>>>> until after a 100% Stable rollout, right? >>>>> >>>> >>>> Yes, that seems reasonable to me. >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2025 at 9:29 PM Domenic Denicola <dome...@chromium.org> >>>>> wrote: >>>>> >>>>>> 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/CAM0wra9rHdU1hd%2BQ6nmhJKiDtDUSnOHToJC5iywR%2Bm7J-2n%3Dzw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9rHdU1hd%2BQ6nmhJKiDtDUSnOHToJC5iywR%2Bm7J-2n%3Dzw%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/CAOMQ%2Bw9GTRCQPNsy81VSZh4mum8FBo455fGMqRdneAZoEmJ_Fg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9GTRCQPNsy81VSZh4mum8FBo455fGMqRdneAZoEmJ_Fg%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/CAFUtAY9w%2Bb75Zuh6RJPqQZPQe5SrfsaBQFq2vfvQuW400AgdMg%40mail.gmail.com.
