Closed Bug 1577243 Opened 5 years ago Closed 5 years ago

Unconditionally clamp the requestAnimationFrame timestamp (and clamp/jitter it in RFP mode)

Categories

(Core :: DOM: Animation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 --- unaffected
firefox70 --- fixed

People

(Reporter: tjr, Assigned: tjr)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.

As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)

This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.

However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)

The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.

In Bug 1387894 we created a mode for Firefox where it unconditionally clamps all timestamps to 20 microseconds. This happens if you disable privacy.reduceTimerPrecision (which is on by default) and is so we don't inadvertently leak super-high-resolution (nanosec) timestamps.

As part of that patch, we started clamping animation timestamps - which are exempted from privacy.reduceTimerPrecision because it was too difficult to get them working at the time. (We should still fix that though.)

This caused new test failures, and one of those was a comparison between document timelines and the timestamp in requestAnimationFrame. we were not clamping the timestamp in requestAnimationFrame under the logic that it fires in predictable intervals.

However discussions about the WPT change we made to 'fix' the now-broken comparison https://github.com/web-platform-tests/wpt/pull/18172 and https://github.com/web-platform-tests/wpt/pull/18357 showed me that document.timeline is supposed to be slaved to the requestAnimationFrame timestamp (or vice versa.)

The correct fix is therefore to unconditionally clamp the requestAnimationFrame timestamp AND the document.timeline timestamp. In doing so we also start clamping/jittering the requestAnimationFrame timestamp in Resist Fingerprinting mode, so that might cause some new/unexpected behaviors for that mode we should watch out for.

Pushed by tritter@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/565a897065e0 Unconditionally clamp the requestAnimationFrame timestamp (and clamp/jitter it in RFP mode) r=birtles https://hg.mozilla.org/integration/autoland/rev/02bfa4baa2ed Backed out changeset cae99e27ccdd, restoring document.timeline and rAF timestamp comparisons r=birtles
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/18750 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Upstream PR merged by moz-wptsync-bot
Regressions: 1577642
Regressions: 1585589
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: