I have a theory for the Windows issue. I think the current rollover protection logic works within a single process but it may not be consistent across different processes. In particular one process my have already registered a rollover and increased its time tick count by 2^32 while another process (spawned later after first rollover) has not and thus their clock will have a constant drift of 2^32 ms. charliea@ any thoughts?

The rollover logic is here:
https://codesearch.chromium.org/chromium/src/base/time/time_win.cc?sq=package:chromium&dr=CSs&l=345

In input event case, timestamp comes from UI process while performance.now() comes from renderer process so this may be possible.

Any update on this?

CCing digit@ and mark@, both of whom seem to have done a lot of work on the Linux timer overflow logic.

Can either of you think of any pathological behavior that would cause Math.round(Event.timeStamp – performance.now) to be almost exactly 2^32 ms on a significant number of Linux computers?

digit@ and mark@: any ideas on the linux case? Here is the rollover logic for event timestamps on linux: https://codesearch.chromium.org/chromium/src/ui/events/x/events_x_utils.cc?l=316


I personally don't have any more ideas on the linux side of this issue. 
There is no repro case at the moment so it is hard to try to get to the
bottom of this for me. Marking the issue as available so it may be picked
up by someone else.