Bug 1577243 - Unconditionally clamp the requestAnimationFrame timestamp (and clamp/jitter it in RFP mode) r=birtles

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.

Differential Revision: https://phabricator.services.mozilla.com/D43788

--HG--
extra : moz-landing-system : lando

layout/base/nsRefreshDriver.cpp

@@ -1720,6 +1720,11 @@ void nsRefreshDriver::RunFrameRequestCallbacks(TimeStamp aNowTime) {
         CallbackDebuggerNotificationGuard guard(
             global, DebuggerNotificationType::RequestAnimationFrameCallback);
 
+        // 0 is an inappropriate mixin for this this area; however CSS Animations
+        // needs to have it's Time Reduction Logic refactored, so it's currently
+        // only clamping for RFP mode. RFP mode gives a much lower time precision,
+        // so we accept the security leak here for now
+        timeStamp = nsRFPService::ReduceTimePrecisionAsMSecs(timeStamp, 0, TimerPrecisionType::RFPOnly);
         // MOZ_KnownLive is OK, because the stack array frameRequestCallbacks
         // keeps callback alive and the mCallback strong reference can't be
         // mutated by the call.