1950992 - Event Timing API sometimes returns incorrect `startTime` (and `duration` because of it)

Status: RESOLVED FIXED

(Core :: DOM: Performance APIs, defect)

Description

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

I noticed this while working on bug 1934683, but then tried it without these patches applied and I can still reproduce it.

It's not 100% reproducible all the time, but I can reproduce it after restarting Firefox a few times. Once it's reproduced, it stays reproducible until another restart.

For example one startTime number I got was -73093753. It looks like an overflow, but don't know why. This also affects the INP values because duration is computed by end - start, so the duration value becomes insanely huge, like 73095163. I wouldn't want numbers like this to be reported by Firefox to websites' RUMs.

I will try to capture and rr session and put the pernosco link here soon.

Comment 1

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

I forgot to mention that I only reproduced this in Linux for now. I'm unsure if it's a cross-platform issue.

Here's a pernosco session: https://pernos.co/debug/JhS0aaIb5UP6qs-wPUfliA/index.html

Comment 2

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Looked at the pernosco session a bit.

aStartTime.mValue = 556261938598153 (from here)
mNavigationStart.mValue = 620023287236088 (from here)

So in this code, when we do aStamp - mNavigationStart, it does 556261938598153 - 620023287236088 which results in a negative number.

I'm still not so sure how it could be happening. Are these timestamps coming from different processes? Event's timestamp comes from the WidgetEventTime class. Are we getting that from the parent process and sending it to the child?

Comment 3

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Paul told me that this is an issue with TimeStamp and we should probably start using AwakeTimeStamp instead.

See bug 1709767 also.

Comment 4

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Attachment: Bug 1950992 - Convert potential 32bit values to 64bit to prevent overflow/underflow during native timestamp conversion r?padenot

In Linux, GTK returns uin32_t values for GdkEventButton.time. It's known that
in the wild we encountered some incorrect values. But the latest I encountered
was in Bug 1950992. It was returning some incorrect values for
WidgetEvent::mTimeStamp. This change should prevent that overflow/underflow.

Comment 5

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

It turned out that this wasn't exactly related to bug 1709767, so removing that. It was about some overflow that we had during native GTK timetamp to TimeStamp conversion.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9e218ec21de2
Convert potential 32bit values to 64bit to prevent overflow/underflow during native timestamp conversion r=padenot

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9e218ec21de2