/pointerevents/pointerevent_click_during_capture.html might not be reasonable

[masayuki-nakano]

Test List

• /pointerevents/pointerevent_click_during_capture.html?mouse-auxclick
• /pointerevents/pointerevent_click_during_capture.html?mouse-click

Rationale

While I'm investigating the behavior change, I found 3 issues.

One is filed as w3c/pointerevents#507. The dblclick event target may be different from click, but is it expected by developers?

The others are filed as w3c/pointerevents#508. The click event target may be different if user inputs from a mouse or touch device. Additionally, current defined behavior is conflict with an old bug fix of Mozilla for web-compat issue in bxSlider (I don't reproduce it with current defined behavior in their example, but the originally reported URL has gone. Therefore, I'm not 100% sure that changing the behavior would break bxSlider again in some cases).

@zcorpan, @smaug----, @mustaqahmed, @flackr

[mustaqahmed]

The WPT still reflects the PEWG's conclusion on click-target as discussed in:

• Should "click", "dblclick" and "contextmenu" events be PointerEvents? w3c/pointerevents#100,
• Rewrite the dispatch algorithm for click-like events w3c/pointerevents#494 and
• https://lists.w3.org/Archives/Public/public-pointer-events/2024JanMar/0006.html.

Moreover, we still don't have an evidence that tested behavior is breaking or not. I guess we won't know until we expose the agreed-upon new behavior, and my understanding is that no browsers tried it (Chromium didn't).

I would suggest using Interop 2024 as a motivation to look into this, and keeping the test unchanged until any browser makes a decisive web-compat observation. We can continue our discussions in the two linked PEWG issues which are a bit orthogonal to this WPT anyway (I just commented in each issue today).

@masayuki-nakano: let us know your thoughts.

[masayuki-nakano]

Sorry, I missed this notification.

Well, but Firefox cannot pass the test until we fix the side-effect of the tricky touch/click element adjustment mentioned at w3c/pointerevents#508 (comment) which does not directly cause the failure...

Cc: @zcorpan, @smaug----

[zcorpan]

Pointer and Mouse events was carried over to Interop 2025, so this is still relevant.

[nairnandu]

@mustaqahmed could you review this proposal since we have carried this over into 2025?

[nt1m]

@aprotyas

[mustaqahmed]

I proposed to carry the test over because we now have conclusive evidence that this behavior is safe for the Web.

Details: The compat risk mentioned here has been discussed in PEWG for a while (to be precise, for 7 years from opening w3c/pointerevents#75 to closing w3c/pointerevents#356). We (Chrome) took the risk to expose this behavior as experimental and heard no complaints from developers in the last 1+ year. This behavior is now enabled for 1% Stable, and expected to be fully enabled in ~a month. See Blink intent to ship.

Also note that the WPT is mouse-only, so touch click targeting is not relevant here.

[mustaqahmed]

During Chrome's Stable experiment, we haven't got any reports of compat problem, yayy!

We are enabling this on 100% Stable starting today, and officially shipping this on M136.

[mustaqahmed]

@masayuki-nakano Can we now close this bug because of the compat confirmation above?

[masayuki-nakano]

Well, I feel it's odd that we close (ignore) this issue (to keep this in Interop 2025) without fixing w3c/pointerevents#507... Does Chrome align the dblclick target as same as click?

[mustaqahmed]

No Chrome does not align dblclick in the same manner, thus matches the spec resolution.

Your dblclick question in w3c/pointerevents#507 is valid but is independent from this particular WPT here: this WPT is fully compliant with the spec resolution w3c/pointerevents#100 and with corresponding spec changes we made over the last few years (like making click and auxclick PointerEvents, fixing their targets and attributes etc).

Let me propose this instead: add dblclick event to this test through a parameter like ?mouse-dblclick which would support your concern through the new test's failures in the WPT dashboard, then close this issue for ?mouse-click and ?mouse-auxclick. @masayuki-nakano let me know your thoughts.

[masayuki-nakano]

The problem for Mozilla is, dblclick event target depends on click event target under current code and it's hard to update it for the current spec especially if it'll be change in the future.