Flickity carousels still animate the same number of frames (but in slow motion) in Firefox with a reduced layout.frame_rate
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: docorbit, Unassigned)
References
Details
Attachments
(1 file)
194.65 KB,
video/webm
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
- Go to about:config
- Search on layout.frame_rate
- Set layout.frame_rate to 2 (meaning 2 frames per second)
- Go to https://japanesetaste.com/products/kikkoman-nama-shoyu-raw-soy-sauce-450ml
- Click on a the chevron to the right of 1/6 on the image
Actual results:
-
Top banner message animates, but renders all frames, producing full-motion animation
-
Next image slides in, but renders all frames, producing full-motion animation
Expected results:
-
Top banner message animates, but renders only 2 frames per second (it doesn't slide in slower; it just doesn't render most frames) (if the slide-in lasts less than half a second, we don't see any animation at all, it just replaces)
-
Next image slides in, but the slide-in renders only 2 frames per second (it doesn't slide in slower; it just doesn't render most frames) (if the slide-in lasts less than half a second, we don't see any animation at all, it just replaces)
Reporter | ||
Comment 1•4 months ago
|
||
The code uses a succession of divs to animate between multiple images.
transform: translateX(0%);
transform: translateX(100%);
transform: translateX(200%);
etc.
The site is using flickity, which has an outstanding issue to respect prefers-reduced-motion https://github.com/metafizzy/flickity/issues/951
Comment 2•4 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•4 months ago
|
||
Thanks for the bug report - I was able to reproduce something sort-of broken, but I'm not sure whether it's the thing you reported or not.
In particular, you mentioned seeing "full motion animation". On Firefox 125 on intel macOS (matching your environment, I think), with layout.frame_rate
set to 2
, I'm not seeing "full motion animation". Rather, I see animation happening at 2 frames per second.
I do notice a bit of brokenness, though: this particular image-carousel seems to insist on rendering the same number of frames regardless of the playback speed, so the animation ends up taking forever. That's outside the control of layout.frame_rate
and unrelated to transforms, though. The site is just manually setting the style
of the element in question to adjust its position, and they're using a requestAnimationFrame
callback to do it, and they don't seem to be accounting for the fact that requestAnimationFrame
might fire at a slower frame rater than they're expecting (for the animation-duration that they're intending to have).
Is this the same brokenness that you were describing -- just that the slide-over animation plays very slowly and moves bit-by-bit when you've throttled the frame rate to 2fps?
If you're seeing something other than that, then I might be missing some additional step or bit of configuration.
Comment 4•4 months ago
|
||
Comment 5•4 months ago
•
|
||
Describing the symptom that I'm seeing another way: it seems that low values for layout.frame_rate
cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames as a user might intuitively expect. Is that the issue you're seeing as well?
I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with requestAnimationFrame()
, and neglecting to account for how much time may have passed between frames).
It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening and we don't know what the end state will be; the site is just asking us to run some blob of JS every time that we're ready to paint (with the state-of-the-word changing arbitrarily on each callback), and we're dutifully doing that, while also respecting the user's wishes to paint (and hence run this JS) at a particular reduced frame rate.
A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that their JS-animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame, which means a slow frame rate means a slow-motion effect.
Comment 6•4 months ago
|
||
I can reproduce this same issue on the main carousel at the top of https://flickity.metafizzy.co/ which seems to be the front-page for this particular carousel library.
Re-reading comment 0, I'm pretty sure the issue that I'm describing is indeed the same issue that you were describing (bad being "renders all frames", good being "doesn't slide in slower; it just doesn't render most frames").
I've filed https://github.com/metafizzy/flickity/issues/1305 to hopefully get this addressed in this particular library, and I'm going to close this as not-a-Firefox-bug, per comment 5.
Comment hidden (typo) |
Reporter | ||
Comment 8•4 months ago
|
||
Hmmm, I'm getting full-speed animation myself.
layout.frame_rate currently set to 1 in Firefox 126.
I have a screen recording showing this but don't see a way to add it to this bug.
Reporter | ||
Comment 9•4 months ago
|
||
I've added the screen recording to your Flickity bug. Not saying the Flickity bug isn't a bug, just that I'm getting different results than you are with the same code. I'm guessing (and it's only a guess) that there is some other setting involved, or, if you're not on a Mac, that the behavior I'm getting is Mac-specific.
Reporter | ||
Comment 10•4 months ago
|
||
Also on Mac, in System Settings, Accessibility, Display, I have Auto-play animated images turned off, although I'm guessing that's a Safari-only setting, as well as Reduce Motion turned on.
Reporter | ||
Comment 11•4 months ago
|
||
And confirmed there must be another setting I've done in about:config which works together with layout.frame_rate to produce the results I'm getting. If I launch a profile with the factory configuration then setting layout.frame_rate to 1 produces the results you are getting.
Comment 12•4 months ago
•
|
||
(In reply to Chas Belov from comment #8)
I have a screen recording showing this but don't see a way to add it to this bug.
There should be an "attachments" section just before your first bug-comment here, with an "attach new file" button. (Though maybe that disappears when the bug is closed, depending on your bugzilla account permissions.)
But in any case, I do see your attachment on the github issue (here) so no pressure/need to attach it here.
(In reply to Chas Belov from comment #11)
And confirmed there must be another setting I've done in about:config which works together with layout.frame_rate to produce the results I'm getting. If I launch a profile with the factory configuration then setting layout.frame_rate to 1 produces the results you are getting.
Do you happen to have privacy.resistFingerprinting
set to true? That does seem to make the animation full-speed here, on my system at least. That's tracked in bug 1863853.
Comment 13•4 months ago
•
|
||
(In reply to Daniel Holbert [:dholbert] from comment #12)
Do you happen to have
privacy.resistFingerprinting
set to true? That does seem to make the animation full-speed here, on my system at least. That's tracked in bug 1863853.
Er, I wasn't quite right on "That's tracked in bug 1863853" -- strictly speaking, bug 1863853 is about a private-browsing-mode specific thing (though it might still be what's happening for you, if you happen to have privacy.resistFingerprinting.pbmode
enabled (note the .pbmode
suffix) and you have a private browsing window open, or you have Firefox configured to never remember history.
Anyway: I've now filed bug 1897251 on the more-straightforward problem of privacy.resistFingerprinting
causing layout.frame_rate
to be ignored. As noted there, this is kind of things working-as-intended, since the whole point of privacy.resistFingerprinting
is to make all users look as-similar-as-possible, which includes things like using a fixed refresh rate (since websites can measure the refresh rate).
(For now, you might consider un-setting privacy.resistFingerprinting
if this is causing usability issues for you; it's mostly intended for the extremely privacy conscious use-cases, in particular TorBrowser, where any fingerprinting at all potentially creates an existential risk, to the point that usability can be sacrificed. That's why it breaks stuff like this. It is possible to create feature-by-feature exceptions to it, but that also reduces its robustness and creates a maintenance burden and I'm not sure what the folks who work on that feature will decide on that point.)
Having said all that: if you don't have any resistFingerprinting
prefs enabled at all and you're still seeing this full-motion animation, please let me know and we can dig further and see if there's some other setting that's breaking layout.frame_rate here.
Reporter | ||
Comment 14•4 months ago
|
||
Excellent detective work! I do in fact have privacy.resistFingerprinting on. I'll review and follow that case; thank you for creating it (as well as for creating your codepen) as well as consider turning off privacy.resistFingerprinting.
Reporter | ||
Comment 15•4 months ago
|
||
For clarification, privacy.fingerprintingProtection.pbmode is set to true, and it's not bolded, so appears to be the browser default.
Comment 16•4 months ago
•
|
||
Right, that's expected and unrelated. The relevant pref for the bug that I referenced (bug 1863853) is privacy.resistFingerprinting.pbmode
which is not quite the same as the one that you referenced, privacy.fingerprintingProtection.pbmode
. (Note "resistFingerprinting" vs. "fingerprintingProtection")
(There are a bunch of extremely-similarly-named prefs for fingerprinting. As I recall, the resistFingerprinting
ones are all off-by-default and not-really-recommended-for-regular-use, to take extreme measures to avoid being fingerprintable" for things like Tor Browser, whereas the fingerprintingProtection
ones are for the more reasonable steps that we can take without breaking the user experience.)
Comment 17•4 months ago
|
||
Thanks again for the bug report! I'm glad we were able to get to the bottom of what was going on. :)
Reporter | ||
Comment 20•4 months ago
|
||
privacy.resistFingerprinting is set to true (overridden), but the rest of the resistFingerprinting options are default.
Comment 21•4 months ago
•
|
||
(In reply to Chas Belov from comment #20)
privacy.resistFingerprinting is set to true (overridden)
Right, that's the one that matters here; that's sufficient to make layout.frame_rate
have no effect. That's bug 1897251, and it's happening because Firefox is trying to aggressively make you look indistinguishable from other users as discussed above. If you reset that to its default state, this bug will go away and your layout.frame_rate
should be respected.
(If you were to turn off that one but enable its .pbmode
version, then you'd see the same issue, but only if you open a private browsing window; that's bug 1863853.)
Description
•