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.
