Bugzilla

(In reply to Chas Belov from comment #1)
> privacy.fingerprintingProtection true (overridden)

Per bug 1894842 comment 20, I think you mean `resistFingerprinting` (not `fingerprintingProtection`).  At least: `resistFingerprinting` is the one that matters for this bug here, and it sounds like you have that one set to true as discussed in bug 1894842.

> I'm getting a different result from Daniel Holbert on this one.

(Hmm -- if you're really seeing differences between those, that's interesting. I can't reproduce that, but it's conceivable; the MDN page is using CSS animations, whereas Flickity is using a JavaScript-driven `requestAnimationFrame` animation.  Let's not dive too far into that here, though, to keep this bug relatively focused; if you want to investigate that difference more, maybe we can do so over on bug 1894842?)

> Please consider whether it might work to deliver the desired layout.frame_rate to the user but lie to the website about the frame rate.

We can't exactly lie to the website about the frame rate -- it's just something that web sites can directly observe.  They can **schedule JavaScript to run on every repaint**, using the requestAnimationFrame API, and then measure how much time passes between those repaints.  (We could in theory still run requestAnimationFrame JS at 60 FPS but only paint every 10th frame for example; but that might cause other site breakage, and it's not really robust since sites have other ways of measuring repaint speed as well.  In any case, it'd be a lot of additional complexity in support of a not-really-supported about:config preference that's kinda only meant for TorBrowser.)

(In reply to Chas Belov from comment #1)
> privacy.fingerprintingProtection true (overridden)

Per bug 1894842 comment 20, I think you mean `resistFingerprinting` (not `fingerprintingProtection`).  At least: `resistFingerprinting` is the one that matters for this bug here, and it sounds like you have that one set to true as discussed in bug 1894842.

> I'm getting a different result from Daniel Holbert on this one.

(Hmm -- if you're really seeing differences between MDN animations page vs. Flickety, that's interesting. I can't reproduce that, but it's conceivable; the MDN page is using CSS animations, whereas Flickity is using a JavaScript-driven `requestAnimationFrame` animation.  Let's not dive too far into that here, though, to keep this bug relatively focused; if you want to investigate that difference more, maybe we can do so over on bug 1894842?)

> Please consider whether it might work to deliver the desired layout.frame_rate to the user but lie to the website about the frame rate.

We can't exactly lie to the website about the frame rate -- it's just something that web sites can directly observe.  They can **schedule JavaScript to run on every repaint**, using the requestAnimationFrame API, and then measure how much time passes between those repaints.  (We could in theory still run requestAnimationFrame JS at 60 FPS but only paint every 10th frame for example; but that might cause other site breakage, and it's not really robust since sites have other ways of measuring repaint speed as well.  In any case, it'd be a lot of additional complexity in support of a not-really-supported about:config preference that's kinda only meant for TorBrowser.)