Closed Bug 1894842 Opened 4 months ago Closed 4 months ago

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)

Product:
Core
Component:
Layout
Version:
Firefox 125
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: docorbit, Unassigned)

References

Details

Attachments

(1 file)

screencast of very slow (~2fps) animation of image=carousel and top-banner
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:

  1. Go to about:config
  2. Search on layout.frame_rate
  3. Set layout.frame_rate to 2 (meaning 2 frames per second)
  4. Go to https://japanesetaste.com/products/kikkoman-nama-shoyu-raw-soy-sauce-450ml
  5. Click on a the chevron to the right of 1/6 on the image

Actual results:

  1. Top banner message animates, but renders all frames, producing full-motion animation

  2. Next image slides in, but renders all frames, producing full-motion animation

Expected results:

  1. 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)

  2. 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)

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

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.

Component: Untriaged → Layout
Product: Firefox → Core

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.

Flags: needinfo?(docorbit)

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.

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Resolution: --- → INVALID
See Also: → https://github.com/metafizzy/flickity/issues/1305

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.

Flags: needinfo?(docorbit)

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.

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.

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.

(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.

(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.

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.

For clarification, privacy.fingerprintingProtection.pbmode is set to true, and it's not bolded, so appears to be the browser default.

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.)

Thanks again for the bug report! I'm glad we were able to get to the bottom of what was going on. :)

privacy.resistFingerprinting.pbmode is set to false (default)

And thank you for your rigorousness.

privacy.resistFingerprinting is set to true (overridden), but the rest of the resistFingerprinting options are default.

(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.)

Noted, thank you.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: