interop
interop copied to clipboard
web-platform-tests
/pointerevents/pointerevent_click_during_capture.html might not be reasonable
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 https://github.com/w3c/pointerevents/issues/507. The dblclick event target may be different from click, but is it expected by developers?
The others are filed as https://github.com/w3c/pointerevents/issues/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
The WPT still reflects the PEWG's conclusion on click-target as discussed in:
- https://github.com/w3c/pointerevents/issues/100,
- https://github.com/w3c/pointerevents/pull/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.
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 https://github.com/w3c/pointerevents/issues/508#issuecomment-2262034441 which does not directly cause the failure...
Cc: @zcorpan, @smaug----
Pointer and Mouse events was carried over to Interop 2025, so this is still relevant.
@mustaqahmed could you review this proposal since we have carried this over into 2025?
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 https://github.com/w3c/pointerevents/issues/75 to closing https://github.com/w3c/pointerevents/issues/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.
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.
@masayuki-nakano Can we now close this bug because of the compat confirmation above?
Well, I feel it's odd that we close (ignore) this issue (to keep this in Interop 2025) without fixing https://github.com/w3c/pointerevents/issues/507... Does Chrome align the dblclick target as same as click?
No Chrome does not align dblclick in the same manner, thus matches the spec resolution.
Your dblclick question in https://github.com/w3c/pointerevents/issues/507 is valid but is independent from this particular WPT here: this WPT is fully compliant with the spec resolution https://github.com/w3c/pointerevents/issues/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.
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.
My $0.02 if this addresses your concerns: we (Chrome) didn't worry about dblclick target changes because it's a legacy event that is way less popular than click, and we haven't seen any report of regressions even for click target changes (https://github.com/web-platform-tests/interop/issues/670#issuecomment-2715583435).
My drive-by take: given the favorable compat results (so far, https://github.com/web-platform-tests/interop/issues/670#issuecomment-2715583435) and given the resolution of https://github.com/w3c/pointerevents/issues/508, I think the ?mouse-click and ?mouse-auxclick variants have fairly reasonable expectations.
We should also introduce a ?mouse-dblclick variant for this test to track the ambiguity raised in https://github.com/w3c/pointerevents/issues/507 but not include it in the interop focus area.
Now, I have patches for Firefox to fix the failures of the test. That will change the dblclick target too due to our limitation. I'll try to land them in the next cycle, 140.
We should also introduce a
?mouse-dblclickvariant for this test to track the ambiguity raised in w3c/pointerevents#507 but not include it in the interop focus area.
Well, I'm not sure whether it's a bug of WebDriver of Firefox, double clicking is not stable, so, the test would cause intermittent failures. In my understanding, there is no way to synthesize a double click which always causes a dblclick event.
Well, I'm not sure whether it's a bug of WebDriver of Firefox, double clicking is not stable, so, the test would cause intermittent failures.
Ah, I'll try experimenting locally and see if I can reproduce with Safari's WebDriver implementation.
Okay, current test should be reasonable, but there should be dblclick test and I believe that the targeting should be aligned to click because it does not make sense to keep maintaining different behavior for legacy event.