Timestamp from requestAnimationFrame() and performance.now() is not coarsened to the same level.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: chrisxuche, Unassigned)
References
(Regression)
Details
(Keywords: regression)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
I noticed that the timestamp obtained from the callback argument of requestAnimationFrame() is not coarsened. In contrast, performance.now() provides a resolution of 100 microseconds on my computer. Although I am not a security researcher, I can't help but wonder if there could be potential timing attacks that exploit the high-resolution timestamp provided by requestAnimationFrame.
Expected results:
Perhaps the timestamp should be coarsened?
Oh, I've made a mistake, timestamp from requestAnimationFrame() is coarsened, but not to the same level as the one from performance.now(), on my computer requestAnimationFrame() has a resolution of 0.1ms while performance.now()'s resolution is 1ms.
function fff(time){
console.log(time);
console.log(performance.now());
}
window.requestAnimationFrame(fff);
You can reproduce the bug using the code above; on my machine the output is:
1941195.4
1941195
|
||
Comment 3•1 years ago
|
||
Tom, any ideas on what we should do with this? Thanks.
|
||
Updated•1 years ago
|
|
||
Updated•1 years ago
|
|
|
||
Updated•1 years ago
|
|
|
||
Comment 4•1 years ago
|
||
Okay, this is behaving this way due to our CSS Animation carveout. It was refactored in Bug 1662277, where we want from using the normal clamping for rAF to using ReduceTimePrecisionAsMSecsRFPOnly. This only affects timestamps if you are RFP mode, otherwise you will get a more granular timestamp than you would from other timers, such as performance.now(). This was needed because CSS Animations behaved really poorly using clamped timestamps (and it was impossible to have invariants like timestamp 1 + timestamp 2 = timestamp 3 be true when they should be.)
The specific code in question is this call here.
So I'm going to mark this Invalid since, while it's not ideal, it's a necessary behavior.
Description
•