Clarify what the target of the click event should be after capturing pointer events #356

smaug---- · 2021-03-31T16:16:30Z

This is split from #75
Testcase

We need some table here to compare the current behavior of various browser engines.

Mousedown on blue. Mouseup on blue.
Mousedown on green. Mouseup on green.
Mousedown on blue. Move to green. Mouseup on green.
Mousedown on green. Move to blue. Mouseup on blue.

patrickhlauke · 2021-04-01T10:29:29Z

https://output.jsbin.com/zuwiwep	Gecko (Firefox 87.0)	Chromium (Chrome 89.0.4389.114)	Webkit (Safari 14.0.3 (16610.4.3.1.4))
1. Mousedown on blue. Mouseup on blue.	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture blue click	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue click blue lostpointercapture	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture blue click
2. Mousedown on green. Mouseup on green.	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture green click	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup grey click blue lostpointercapture	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture green click
3. Mousedown on blue. Move to green. Mouseup on green.	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture green click	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue click blue lostpointercapture	blue pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture grey click
4. Mousedown on green. Move to blue. Mouseup on blue.	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture blue click	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup grey click blue lostpointercapture	green pointerdown Set pointer capture to blue div blue gotpointercapture blue pointerup blue lostpointercapture grey click

flackr · 2021-04-14T16:23:11Z

My intuition is that because the pointer capture effectively targets all events at the captured element, it should at least override the target of the up event when determining the common ancestor for the click. This seems to match chrome's current behavior, specifically,

blue click
grey click
blue click
grey click

However, I think we may want to go further and consider setting capture to have effectively changed the down target to be blue as well. This would make all 4 cases a blue click.

smaug---- · 2021-04-28T14:40:21Z

The more I think, the better having click firing on the capture target feels. Otherwise click may fire basically in any random ancestor. However, if capture is released explicitly before *up event, then it wouldn't affect click targeting.

mustaqahmed · 2021-05-05T18:58:36Z

I am looking into measuring in Chrome the fraction of page-loads that have different pointerdown and pointerup targets for explicit pointer captures for primary pointers.

In PEWG, we are considering making the target of a click event the same as the pointerup target when the pointerup event is dispatched to a captured target. Currently the click event target is the common ancestor of pointerdown and pointerup targets. Before we make the change, we want to check what fraction of page loads would be affected by this possible change in click target. Spec discussion: w3c/pointerevents#356 Fixed: 1199099 Change-Id: I9e28c9ab5138f187635352a74befb8cb800aa80a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2876145 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#893096}

mustaqahmed · 2021-06-17T13:59:48Z

In Chrome we just landed a counter for this measurement. We will update this thread when we have sufficient data...in the worst case it could be a few months if we have to wait for next Stable release.

mustaqahmed · 2021-07-09T15:33:48Z

FYI: We got a Chrome bug few days ago reporting an unclickable link that works in Safari. The site is using pointercapture to a parent element and expecting click in a child element. Based on our discussion here, I closed the bug as "working as intended".

flackr · 2021-07-09T17:44:32Z

This bug gets into the more complicated area of releasing capture. The case in the bug is clicking on descendant in the following:

<div id="a">
  <div id="b"></div>
</div>
<script>
a.addEventListener('pointerdown', (e) => {
  a.setPointerCapture(e.pointerId);
});
a.addEventListener('pointerup', (e) => {
  a.releasePointerCapture(e.pointerId);
});
b.addEventListener('click', (e) => {
  console.log('clicked');
});
</script>

The capture is released before the click event, which raises questions about whether click should no longer be captured.

In this particular case, it shouldn't matter since I'd argue that the pointerup was captured so the click target should still be the common ancestor of the captured up event (i.e. #a) and the down event (i.e. #b), so we would target the click at #a and not fire the click event.

However, what if we set pointer capture on a different element?

<body>
  <div id="a">
    <div id="b">
    </div>
  </div>
  <div id="c"></div>
</body>
<script>
a.addEventListener('pointerdown', (e) => {
  c.setPointerCapture(e.pointerId);
});
c.addEventListener('pointerup', (e) => {
  c.releasePointerCapture(e.pointerId);
});
c.addEventListener('click', (e) => {
  console.log('clicked');
});
</script>

Do we consider the captured pointerup to have also captured the corresponding click even though it hasn't been dispatched yet? Or would we target the click at the common ancestor of the down event target (#b) and up event target (#c), i.e. the body.

mustaqahmed · 2021-07-09T20:46:58Z

To me, the two cases you mentioned look exactly the same as clicking respectively on "blue" and "green" in the original repro. Yes, the original repro releases implicitly, and yours releases explicitly. But in both cases, pointerup is dispatched before release and click is dispatched after release. What am I missing here?

flackr · 2021-07-11T17:59:05Z

But in both cases, pointerup is dispatched before release and click is dispatched after release.

This is the question really. If you never explicitly release capture, shouldn't the click be captured as well? I.e. dispatched to #c in my second example. In fact it seems the spec explicitly says that the click should still be captured under implicit release of pointer capture:

If the user agent supports firing the click event (see compatibility mouse events), and if in an implicit release scenario both click and lostpointercapture events are fired, click SHOULD be fired before lostpointercapture.

As such, it seems that the click should be captured and #c should be the click target in my second example.

jakearchibald · 2021-08-19T10:52:22Z

A similar case to think about:

<div><button></button></div>

Pointer down on button.
button.style.pointerEvents = 'none';
Pointer up without moving.

All browsers seem to agree that the div gets the click. In which case, shouldn't this behave the same?:

Pointer down on button.
Outer div captures the pointer.
Pointer up without moving.

jakearchibald · 2021-08-19T11:40:58Z

I guess all the other cases have equivalents where elements move around after pointerdown. Seems reasonable to be consistent with that?

Here's a remix of the test case https://output.jsbin.com/masazab/3/. The results seem more consistent with what Chrome is currently doing with pointer capture.

smaug---- · 2021-08-19T17:30:23Z

pointerEvents css case has very little to do with this. Hit test in that case gets to the div element, so div should get the click.

jakearchibald · 2021-08-20T09:24:45Z

In the pointerEvents case, the outer div gets the events because the button can no longer get pointer events. In the capture case, the outer div gets the events because the div has captured the pointer.

Isn't that roughly the same in terms of event targeting?

smaug---- · 2021-08-20T09:33:43Z

It is quite different from hit testing and from API usage point of view.
When you're capturing, you can avoid hit testing, and also the user of the API has asked events to go to a certain element.

jakearchibald · 2021-08-20T12:06:07Z

also the user of the API has asked events to go to a certain element

With pointerEvents they've asked for events to avoid a particular element, which makes it go to the one underneath. That seems pretty similar in terms of expected outcome in this case. But eh, I don't have a lot of experience with the spec here, I'm just speaking as a web dev.

masayuki-nakano · 2022-02-21T03:23:52Z

Releasing a button outside capturing element causes click event seems odd because it makes harder to consider whether user clicks on the element or outside (it typically means users cancel to click the stuff). So I'd love that releasing a button outside capturing stuff (including DOM window) does not cause click event in any EventTargets because user clicks nothing actually. On the other hand, if web apps in the wild have already depended on Chrome's behavior, it may be reasonable that the other browsers follow it.

maximecb · 2022-03-11T04:38:48Z

Posting here because I'm working on a web app which uses setPointerCapture and has a fairly complex use case, namely a graph editor (https://noisecraft.app/101). I keep running into inconsistencies into the way pointer capture works across Chrome/Safari/FF and it's driving me insane.

I really think Chrome has the best behavior with respect to pointer capture and click. The way I think of it, while an element has pointer capture, it "owns" all of the mouse events. It allows the capturing element to implement its own behavior until the capture is released. I really think this is the most intuitive behavior and what most people will want.

In my specific use case, my graph editor has a knob node, and you can "grab" the knob with your pointer to change its value. This involves clicking on the knob and then moving the mouse outside of the knob's area, and releasing the knob when you've reached the value you want. In Chrome this works well, in Firefox and FF, a click event gets triggered elsewhere. This is forcing me to either avoid relying on onclick, or resort to awful hacks like having an invisible fullscreen div to prevent any other DOM elements from receiving the click...

So please, please, please, make it so that click is sent to the event that started the pointer capture. This is the only sensible answer.

smaug---- · 2022-04-13T12:08:18Z

The problem is that capture is released before click is dispatched. Per current specifications click is dispatched to the common ancestor of *down and *up events.

masayuki has a good point too and I think if the API hadn't been shipping now for years, I'd go with that behavior. But since the
API has been there for quite some time perhaps we could go with the #356 (comment) .
That could be used to fix #357 too. We would need to change
https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture

That leaves still though the question where click should be dispatched if capture was explicitly released in pointerup. In that case I would expect click to go to the common ancestor of down/up.

One thing to think about is that click event often opens new windows or may trigger alert() etc. I believe those wouldn't cause problems here, but anyhow something to keep in mind.

mustaqahmed · 2022-04-13T16:16:57Z

Just realized that the Chrome behavior mentioned in #356 (comment) is only for mouse pointers! For touch pointers, the click is dispatched asynchronously (to be able to distinguish click on tap vs auxclick on long-tap) after both pointerup and lostpointercapture has been dispatched, fully matching Firefox!

And this behavior has been there since we (Chrome) shipped PointerEvents!

We never got a chance to report the counter data we added a while ago (#356 (comment)). Expecting to report back in a week.

flackr · 2022-04-13T17:07:48Z

That leaves still though the question where click should be dispatched if capture was explicitly released in pointerup. In that case I would expect click to go to the common ancestor of down/up.

+1 I agree. The common ancestor of the down/up targets makes sense if you have explicitly released capture.

smaug---- · 2022-04-19T17:58:37Z

Hmm, I guess we need to test also other mobile browsers. I don't have access to Safari, but will test Firefox on Android in a moment.

smaug---- · 2022-04-19T19:46:35Z

Mobile Firefox (Android) works in cases 1 and 2 like desktop, and 3 and 4 don't dispatch click.
(I don't get click on mobile Chrome either in cases 3 and 4)

smaug---- · 2022-04-27T15:28:03Z

Given that all the browsers do different things, we're going to take a look at whether it was possible to implement setup where lostpointercapture is fired after click, and click's target is the captured element.

EdgarChen · 2022-04-29T11:54:58Z

Given that all the browsers do different things, we're going to take a look at whether it was possible to implement setup where lostpointercapture is fired after click, and click's target is the captured element.

It sounds reasonable.

That leaves still though the question where click should be dispatched if capture was explicitly released in pointerup. In that case I would expect click to go to the common ancestor of down/up.

So the lostpointercapture is fired before click event if the capture was explicitly released in pointerup, right? Then the whole setup makes sense.

smaug---- · 2022-04-29T15:50:42Z

yes, if one explicitly releases capture, then the behavior should be that.

mustaqahmed · 2022-07-05T22:03:37Z

Here is the same testcase but for testing with touch. The only difference here is the touch-action:none to suppress touchcancel on finger drag. We will discuss all Chrome bugs with mouse+touch tomorrow.

mustaqahmed · 2022-07-06T16:06:35Z

Here are the Chrome bugs we filed:

https://crbug.com/1342209 on mouse event order
https://crbug.com/1342214 on touch event order
https://crbug.com/1342219 on missing click with touch drag
[mouse+touch] https://crbug.com/1342248 on explicit pointer capture release

This new test page now covers touch-action:none and explicit release.

In PEWG, we are considering making the target of a click event the same as the pointerup target when the pointerup event is dispatched to a captured target. Currently the click event target is the common ancestor of pointerdown and pointerup targets. Before we make the change, we want to check what fraction of page loads would be affected by this possible change in click target. Spec discussion: w3c/pointerevents#356 Fixed: 1199099 Change-Id: I9e28c9ab5138f187635352a74befb8cb800aa80a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2876145 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#893096} NOKEYCHECK=True GitOrigin-RevId: d424e6fa4b7c39e4961a0e681072b7b5c6c3655f

patrickhlauke · 2023-05-10T14:54:32Z

Latest results using the new test page, with touch-action and explicit release checked

https://codepen.io/mustaqahmed/full/YzawKWW with `touch-action` and explicit release	Chrome 113.0.5672.93 / Win / mouse	Firefox 113.0 / Win / mouse	Safari 16.4 (18615.1.26.11.23) / macOS	Safari 16.4 / iOS / touch	Chrome 110.0.5481.153 / Android 11 / touch
1. Mousedown on blue. Mouseup on blue.	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue click blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture blue click
2. Mousedown on green. Mouseup on green.	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) grey click blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture green pointerup (explicitly release pointer capture from blue) blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture green click
3. Mousedown on blue. Move to green. Mouseup on green.	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue click blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture green click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture grey click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture
4. Mousedown on green. Move to blue. Mouseup on blue.	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) grey click blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture blue click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture grey click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup (explicitly release pointer capture from blue) blue lostpointercapture

patrickhlauke · 2023-05-10T23:11:15Z

Latest results using the new test page, with touch-action and explicit release not checked (I also added Firefox/Android for completeness)

https://codepen.io/mustaqahmed/full/YzawKWW with `touch-action` but NO explicit release	Chrome 113.0.5672.93 / Win / mouse	Firefox 113.0 / Win / mouse	Safari 16.4 (18615.1.26.11.23) / macOS	Safari 16.4 / iOS / touch	Chrome 110.0.5481.153 / Android 11 / touch	Firefox 109.2.0 / Android 11 / touch
1. Mousedown on blue. Mouseup on blue.	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue click blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture blue click	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture blue click
2. Mousedown on green. Mouseup on green.	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup *[grey click]* blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture *[green pointerup]* blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture green click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture green click
3. Mousedown on blue. Move to green. Mouseup on green.	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup *[blue click]* blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture *[green click]*	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture *[grey click]*	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture	blue pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture
4. Mousedown on green. Move to blue. Mouseup on blue.	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup grey click blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture *[blue click]*	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture grey click	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture	green pointerdown (set pointer capture to blue) blue gotpointercapture blue pointerup blue lostpointercapture

patrickhlauke · 2023-06-05T11:20:10Z

edited the above table to just highlight (bold, italic, square brackets) the outliers (the click events, and that one "green pointerup" in row 2 for Safari on iOS)

patrickhlauke · 2023-06-13T08:38:08Z

heads-up: i forked/extended @mustaqahmed's codepen to also include mousedown/mouseup per https://www.w3.org/2023/06/07-pointerevents-minutes.html#a02 (and added a little quality of life improvement with a button to clear the log)

https://codepen.io/patrickhlauke/full/MWzapmz

I'll rerun the tests and post the results here.

flackr · 2023-06-14T20:02:14Z

After doing a deep dive into this I feel like if the pointerup was captured we should send the click to blue. I think this makes sense even in cases when the capture has been explicitly released or lost because the click is not independently targeted but depends on the down and up events. Since the up which resulted in the click was captured - I think it's reasonable that this becomes the click target.

I don't think we need to send boundary events because we already don't send boundary events that would be implied by the click going to the common ancestor. E.g. without pointer capture pressing down on green and up on blue will send click to gray without sending mouseout to blue.

One use case we came up with is if you had a slider with a thumb but you wanted to give it a generous hit testing area by setting pointer capture. It seems reasonable that the click should go to the thumb whether the initial down event actually hit it or not.

mustaqahmed · 2023-06-14T21:03:26Z

Thanks @flackr for the discussion today, I agree with your conclusion above. The main takeaway for me is that even in the traditional MouseEvent world (without capturing), click as a high-level event is not tied to any single low-level event (i.e. mousedown, mousemove and mouseup), and its target is not affected by the effective position of the pointer implied by the boundary events (mouseenter, mouseleave, mouseover and mouseout).

It is logical that the PointerEvents spec would extend this special targeting behavior to include Pointer Capture: the click target would be unaffected by the effective pointer target implied by gotpointercapture and lostpointercapture events for the same pointerid. This would make the click behavior more developer-friendly, and doesn't seem to pose any impl challenge even for asynchronous click from touch. And the compat question is irrelevant for obvious reasons.

smaug---- · 2023-06-18T16:20:15Z

I think I agree with @flackr that blue should be the click target since that is where the capture was.

(and once this is resolved, there is still #357 )

mustaqahmed · 2024-02-14T21:33:58Z

I just confirmed that pointerevent_click_during_capture.html is already up-to-date with the spec. In fact, the WPT was updated before the spec change above.

I will add a similar test for auxclick.

This CL adds/fixes two WPTs to match two recent spec resolutions: w3c/pointerevents#356 w3c/pointerevents#357 - Fixes the WPT for click target with capture, and - Adds a similar WPT for auxclick. Bug: 40851618 Change-Id: Ide9da78897cd7a03135a2d70f41cade1e00cb2f3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5301480 Commit-Queue: Robert Flack <flackr@chromium.org> Auto-Submit: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1264738}

mustaqahmed · 2024-02-26T14:50:06Z

Done with WPT.

… match PointerEvent spec., a=testonly Automatic update from web-platform-tests [Interop] Fix/add click/auxclick WPTs to match PointerEvent spec. This CL adds/fixes two WPTs to match two recent spec resolutions: w3c/pointerevents#356 w3c/pointerevents#357 - Fixes the WPT for click target with capture, and - Adds a similar WPT for auxclick. Bug: 40851618 Change-Id: Ide9da78897cd7a03135a2d70f41cade1e00cb2f3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5301480 Commit-Queue: Robert Flack <flackr@chromium.org> Auto-Submit: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1264738} -- wpt-commits: 8960484e82396a39b2cedd684d53b983f9d22ac4 wpt-pr: 44758

In PEWG, we are considering making the target of a click event the same as the pointerup target when the pointerup event is dispatched to a captured target. Currently the click event target is the common ancestor of pointerdown and pointerup targets. Before we make the change, we want to check what fraction of page loads would be affected by this possible change in click target. Spec discussion: w3c/pointerevents#356 Fixed: 1199099 Change-Id: I9e28c9ab5138f187635352a74befb8cb800aa80a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2876145 Commit-Queue: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/master@{#893096} Former-commit-id: d424e6fa4b7c39e4961a0e681072b7b5c6c3655f

This CL adds/fixes two WPTs to match two recent spec resolutions: w3c/pointerevents#356 w3c/pointerevents#357 - Fixes the WPT for click target with capture, and - Adds a similar WPT for auxclick. Bug: 40851618 Change-Id: Ide9da78897cd7a03135a2d70f41cade1e00cb2f3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5301480 Commit-Queue: Robert Flack <flackr@chromium.org> Auto-Submit: Mustaq Ahmed <mustaq@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1264738} Former-commit-id: 776d15695623e52b9d8a571d97f43229debe04a9

This was referenced Apr 14, 2021

Click event while a pointer event is captured #75

Closed

Clarify when lostpointercapture should fire #357

Closed

patrickhlauke added the v3 label Apr 21, 2021

mustaqahmed self-assigned this May 5, 2021

jakearchibald mentioned this issue Aug 19, 2021

Behavior change caused by introduction of setPointerCapture() mrdoob/three.js#22353

Closed

mustaqahmed mentioned this issue Jun 21, 2023

Define target and event-order for click, auxclick and contextmenu events #474

Merged

mustaqahmed closed this as completed in #474 Jul 4, 2023

m-bert mentioned this issue Jul 18, 2023

Releasing a Manual Gesture over a RN Pressable causes onPress to be fired. (WEB) software-mansion/react-native-gesture-handler#2388

Open

smaug---- added the needs-wpt Investigation whether the issue needs a wpt test has been done and wpt is missing label Sep 28, 2023

jgraham mentioned this issue Feb 7, 2024

Test change proposal for pointer events web-platform-tests/interop#628

Closed

chromium-wpt-export-bot mentioned this issue Feb 23, 2024

[Interop] Fix/add click/auxclick WPTs to match PointerEvent spec. web-platform-tests/wpt#44758

Merged

mustaqahmed removed the needs-wpt Investigation whether the issue needs a wpt test has been done and wpt is missing label Feb 26, 2024

Clarify what the target of the click event should be after capturing pointer events #356

Clarify what the target of the click event should be after capturing pointer events #356

Comments

smaug---- commented Mar 31, 2021 • edited

patrickhlauke commented Apr 1, 2021 • edited

flackr commented Apr 14, 2021

smaug---- commented Apr 28, 2021

mustaqahmed commented May 5, 2021

mustaqahmed commented Jun 17, 2021

mustaqahmed commented Jul 9, 2021

flackr commented Jul 9, 2021

mustaqahmed commented Jul 9, 2021 • edited

flackr commented Jul 11, 2021

jakearchibald commented Aug 19, 2021

jakearchibald commented Aug 19, 2021

smaug---- commented Aug 19, 2021

jakearchibald commented Aug 20, 2021

smaug---- commented Aug 20, 2021

jakearchibald commented Aug 20, 2021

masayuki-nakano commented Feb 21, 2022

maximecb commented Mar 11, 2022

smaug---- commented Apr 13, 2022 • edited

mustaqahmed commented Apr 13, 2022

flackr commented Apr 13, 2022

smaug---- commented Apr 19, 2022

smaug---- commented Apr 19, 2022

smaug---- commented Apr 27, 2022

EdgarChen commented Apr 29, 2022

smaug---- commented Apr 29, 2022

mustaqahmed commented Jul 5, 2022

mustaqahmed commented Jul 6, 2022 • edited

patrickhlauke commented May 10, 2023 • edited

patrickhlauke commented May 10, 2023 • edited

patrickhlauke commented Jun 5, 2023 • edited

patrickhlauke commented Jun 13, 2023

flackr commented Jun 14, 2023

mustaqahmed commented Jun 14, 2023

smaug---- commented Jun 18, 2023

mustaqahmed commented Feb 14, 2024

mustaqahmed commented Feb 26, 2024

smaug---- commented Mar 31, 2021 •

edited

patrickhlauke commented Apr 1, 2021 •

edited

mustaqahmed commented Jul 9, 2021 •

edited

smaug---- commented Apr 13, 2022 •

edited

mustaqahmed commented Jul 6, 2022 •

edited

patrickhlauke commented May 10, 2023 •

edited

patrickhlauke commented May 10, 2023 •

edited

patrickhlauke commented Jun 5, 2023 •

edited