Closed Bug 1318524 Opened 8 years ago Closed 7 years ago

Normalize event.timeStamp to when events were received by the browser

Categories

(Core :: DOM: Events, defect, P2)

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: Harald, Assigned: ben.tian)

Details

I keep hearing that timeStamps are a mess now, getting better with bug 1026804; but we still don't have high-res values on OSX and Linux (and Fennec?).

The Chrome perf team mentioned that some OSs provide garbage timestamps, which is why they switched to set the event timestamp to when the event was received by the browser.

This not only makes the data much cleaner but also provides much better insights into event handling delays in the browser vs the OS; which we often we can not optimize away.
mccr8 recommended :smaug
Flags: needinfo?(bugs)
I've been waiting for bug 1026804 to get fixed.
Flags: needinfo?(bugs) → needinfo?(bbirtles)
I have people assigned to the dependent bugs as part of their goals for Q4. Sorry about the delay--previously someone promised to do the work then backed out of it months later without explanation.
Flags: needinfo?(bbirtles)
Priority: -- → P2
Yet another events bugs for you, Ben :)
Flags: needinfo?(btian)
Take the bug.
Assignee: nobody → btian
Flags: needinfo?(btian)
I'm afraid I don't quite understand the exact purpose of this bug? Which OSes do you want to adjust and in what manner? We have high-res timestamps on all platforms now.

If we just use TimeStamp::Now() when the event is received, we will have less accurate timestamps when the browser is under load. The current OS-time to TimeStamp conversion code for Windows and Linux at least provides skew-detection which should insulate us from some possible sources of OS timestamp variance.

If you are encountering less useful timestamps on Android, for example, then perhaps you could clamp timestamps so that they are at least monotonically increasing for a given event source, I suppose.
Flags: needinfo?(hkirschner)
> If you are encountering less useful timestamps on Android, for example, then perhaps you could clamp timestamps so that they are at least monotonically increasing for a given event source, I suppose.

Sounds like we are not sure if we can fully trust the provided timestamps. The background here is that Chrome engineers mentioned that they got very unreliable timestamps for windows (afaik). Would it be useful to have telemetry on how much we get "bogus" timestamps from the OS?
Flags: needinfo?(hkirschner)
I'm not aware of any particular issues on Windows. It's possibly Chrome doesn't do the clock skew adjustment that we do on Windows.
Per comment 6 and 8, I tend to resolve this bug as INCOMPLETE for no clear problem observed or repro steps. Feel free to reopen with more details or clear problem observed to support this change.

Harald, how do you think?
Flags: needinfo?(hkirschner)
Resolve INCOMPLETE per comment 9. Feel free to reopen with clearer problem description.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
I also don't have more details on what this would fix. If event timestamp as an issue comes up again we can revisit.
Flags: needinfo?(hkirschner)
You need to log in before you can comment on or make changes to this bug.