1885287 - Failing WPTs in /pointerevents/coalesced_events_attributes_under_load.https.html?mouse

Status: ASSIGNED

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

Description

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

See https://wpt.fyi/results/pointerevents/coalesced_events_attributes_under_load.https.html%3Fmouse.

Comment 1

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

I think that the test is invalid. It tests 2 or more mousemove or touchmove events are coalesced and they appear as coalesced pointermove events. However, it tries to do things tricky to make the content process busy. However, there is no guarantee that browsers make synthesized events coalesced. At least, Gecko coalesces eMouseMove and eTouchMove events when a content process received. I.e., synthesized events are not cross the process boundary, they won't be coalesces. Additionally, even if I enable test.events.async.enabled to make all events came from the parent process with a patch for bug 1914560 (which implements coalesced events for synthesized events), we won't pass the test.

So, I think that we can suggest it should be dropped from the scope of interop 2024 at least. WDYT, zcorpan?

FYI: all browsers fail this test.

Comment 2

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

FYI: Enabling the pref and applying the patch makes Gecko fail the test with same reason as Chrome.

Comment 3

[Simon Pieters [:zcorpan]]

Sounds good. I was going to suggest filing a test change proposal, but https://github.com/web-platform-tests/interop/issues/690 was just filed today.

Comment 4

[Mustaq Ahmed]

We just renamed the test to ".optional.html" because the main assert here enforces an optional part of the spec. We should have instead included "pointerevents/coalesced_events_attributes.https.html?mouse" in Interop, apologies for missing this. Let's discuss the next steps in the github issue.

Comment 5

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

Thank you!

When I check the scope of Interop 2024, coalesced_events_attributes.https.html?mouse was already in the scope and I started to work on it (bug 1914560).