Intent to Ship: Dispatching click events to captured pointer

[Mustaq Ahmed]

Contact emails

mus...@chromium.org

Explainer

https://w3c.github.io/pointerevents/#event-dispatch

Specification

https://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 component

Blink>Input

TAG review

None

TAG review status

Not 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).

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?

Yes

https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=pointerevents%2Fpointerevent_click_during_capture.html

Flag name on about://flags

None

Finch feature name

ClickToCapturedPointer

Requires code in //chrome?

False

Tracking bug

https://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.

[Mike Taylor]

On 2/5/25 10:11 AM, Mustaq Ahmed wrote:

Contact emails

mus...@chromium.org

Explainer

https://w3c.github.io/pointerevents/#event-dispatch

Specification

https://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 component

Blink>Input

TAG review

None

TAG review status

Not 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).

You mention difference in behavior between browsers - can you clarify what they all do today?

Also, have we done any compat analysis to have confidence in the "slight risk" mentioned here?

Gecko: Positive (https://github.com/w3c/pointerevents/issues/356#issuecomment-1596196064)

WebKit: No signal

Can we please ask for formal signals from both Mozilla and Apple?

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5WP0%3DEV2%3DiQkS2Bkt8z4fKnfMFNBNeBEU76xOSsYNCHA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

On Wed, Feb 5, 2025 at 4:11 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Contact emails

mus...@chromium.org

Explainer

https://w3c.github.io/pointerevents/#event-dispatch

Specification

https://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 component

Blink>Input

TAG review

None

TAG review status

Not 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?

 

--

[Mustaq Ahmed]

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?

[Domenic Denicola]

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4kZU5RxQiMGhMZqkDdPqGsdZLUd11bFY5xbyoizvFkhQ%40mail.gmail.com.

[Mustaq Ahmed]

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, 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 Perhaps we can defer this until after a 100% Stable rollout, right?

[Domenic Denicola]

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, 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 Perhaps we can defer this until after a 100% Stable rollout, right?

Yes, that seems reasonable to me.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9rHdU1hd%2BQ6nmhJKiDtDUSnOHToJC5iywR%2Bm7J-2n%3Dzw%40mail.gmail.com.

[Rick Byers]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9GTRCQPNsy81VSZh4mum8FBo455fGMqRdneAZoEmJ_Fg%40mail.gmail.com.

[Mustaq Ahmed]

This feature and the UseCounter stats mentioned above are for mouse clicks 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)!!

[Rick Byers]

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