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.
