Should pointer events and compatibility mouse events have the same timestamp?

[graouts]

I'm asking this because one of the WPT tests (pointerevent_suppress_compat_events_on_drag_mouse.html) expects it to be the case but I can't find anything in the spec to back that up. Either this should be made clear in the spec or that assertion should be removed. I've raised an issue on wpt about that at web-platform-tests/wpt#17016.

[NavidZ]

I believe compatibility mouse events are the non-normative part of the spec. So in that sense we shouldn't even need to have the test for it. Having said that, there are some tests that just check the current common behaviors of the implementors without having the exact specification for it. Like the one you mentioned.
I would love to ask your opinion about the behavior first. Do you think that is a reasonable expectation or have you faced scenarios that you might want to send compat mouse events and this timestamp assertion didn't make sense?
If you also think this is reasonable and you are planning to follow the same pattern in Webkit this might be the time to explicitly call this out in the spec as well. But again that whole section is non-normative.

[graouts]

I don't really see the value in ensuring that the timestamp is the exact same value, at least it doesn't seem like a good idea to me for an author to rely on this kind of data to make any kind of assumption. I might also be biased by the extra work required to make this work in WebKit :) So I would advocate that we remove the specific part of the test about equal timestamps.

[NavidZ]

I don't mind removing that from the tests. @smaug---- WDYT?

[graouts]

If we're in agreement, I have a PR to change the test at web-platform-tests/wpt#17041.

[RByers]

I agree the spec doesn't require this, so relaxing the tests seems fine.

That said, a couple years ago I believe we did get agreement that Event.timeStamp was the right way to measure input latency. So it would seem confusing to me for a pointerdown to have a different start time from it's equivalent mousedown - it would suggest that one or the other doesn't really reflect the real input latency. Isn't there a risk that this could break sites own measurements of their input latency? It looks like the FID polyfill just pays attention to the first event it sees and listens for both pointerdown and mousedown so as long as WebKit uses the real original timeStamp for pointerdown it should be OK. But others may not be.