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/CAFUtAY-Xn1mERGB%2BfX%3DXZqwhP2g14pU3S_N4aXq%3D-gDHUWX1Sw%40mail.gmail.com.
