1755752 - setPointerCapture doesn't capture "click" events

Status: RESOLVED DUPLICATE of bug 1556240

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Julien Wajsberg [:julienw]]

Attachment: pointercapture.html

STR:

1. Load the attachment.
2. mousedown on the inner square.
3. mouseup outside of the inner square.

Expected: all events are retargeted to the inner square.
Actual: all events but the click event are retargeted to the inner square.
Except when the mouseup happens outside of the window (the contrary of bug 1755746). I also tried the STR from Bug 1755498, which isn't fixed by setPointerCapture.

Chrome behaves as expected.

In this attachment, pointerdown on the inner square calls setPointerEvent on the square. This makes it possible to compare what happens when starting the gesture on another element.

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: setcapture.html

Same STR using setCapture (which isn't standardized and is supported in Firefox only) works perfectly well, including fixing issues from bug 1755746 and Bug 1755498 (update: the latter bug isn't fully fixed, especially when the <button> is inside the capturing element...) .

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Firing click event on the <div class="inner"> seems odd to me because even if the mouse cursor is captured explicitly, user did not click the element...

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This was discussed in https://github.com/w3c/pointerevents/issues/356, but it's not yet closed.

However, according to https://bugs.chromium.org/p/chromium/issues/detail?id=1224677#c12, mustaq claimed that it's agreed as Chrome's behavior.

Smaug: do you agree with the reported expectation?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

In my understanding, click event should be fired when mousedown and mouseup are fired on same stuff for allowing web apps to handle users' decision easier. So I think that click event should not be fired in the capturing element nor any ancestors because user release outside of the target. On the other hand, web apps in the wild have already depended on the Chrome's behavior, it's reasonable to follow it.

Comment 5

[Julien Wajsberg [:julienw]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)

You're saying:

In my understanding, click event should be fired when mousedown and mouseup are fired on same stuff for allowing web apps to handle users' decision easier.

In this case, mousedown and mouseup are both fired at the inner square.

So I think that click event should not be fired in the capturing element nor any ancestors because user release outside of the target.

So I don't understand your rationale here :-)

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Julien Wajsberg [:julienw] from comment #5)

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)

You're saying:

In my understanding, click event should be fired when mousedown and mouseup are fired on same stuff for allowing web apps to handle users' decision easier.

In this case, mousedown and mouseup are both fired at the inner square.

Yes, because of web apps' capture, not by user operation.

So I think that click event should not be fired in the capturing element nor any ancestors because user release outside of the target.

So I don't understand your rationale here :-)

In my understanding, mousedown and mouseup events are device's physical state change events. On the other hand, click event is a logical event of a user's action (like keydown/keyup vs. keypress). I don't think that the user intents to click the element when releasing the mouse button on outside the capturing element. This is the reason why I don't think that click event should be fired in this case. The click event which does not match to user's intention may be treated as a click by the web apps.

Comment 7

[Julien Wajsberg [:julienw]]

Thanks, I understand better your thinking.
The spec says clearly in [1] that click and contextmenu aren't part of the compatibility mouse events, and that user agents may decide to not fire them due to some conditions. So this is totally in line with the spec.

[1] https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Aligning to Webcompat priority.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Yeah, this is complicated and based on the spec issue Chrome for example isn't even consistent with itself - desktop and mobile behave differently.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #9)

Yeah, this is complicated and based on the spec issue Chrome for example isn't even consistent with itself - desktop and mobile behave differently.

Thanks, aligning to inconsistent behavior even in Chrome seems risky thing...

Comment 11

[Julien Wajsberg [:julienw]]

Chrome on Android has a weird behavior indeed, we never even get the pointerup once we start moving the finger, as it looks like other gestures are used instead. Therefore I believe this is a completely different thing.

Comment 12

[Julien Wajsberg [:julienw]]

Firefox on Android seems to have the same behavior as Chrome on Android.

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Looks there's a resolution for this issue, see https://github.com/w3c/pointerevents/issues/357 and https://github.com/w3c/pointerevents/issues/356

Comment 15

[Erik Demaine]

I recently ran into this bug, and I find the current Firefox behavior pretty wild. Here's my reproduction, but I think this demo from https://github.com/w3c/pointerevents/issues/356 is even clearer. Clicking on one object (e.g. green), and dragging to another (e.g. blue), triggers clicking on the latter object (blue), even though that object never got a mousedown/pointerdown event, which is clearly against the definition of "click". Anyway, it's great that the standard is now settled so we can converge on a single behavior.