1971509 - Remove all transition effects (even pop-up fades) in chrome when OS animation effects are disabled

Status: VERIFIED FIXED

(Toolkit :: Themes, defect)

Description

[Michal Čaplygin [:myf]]

While opacity animations don't trigger vestibular disorders, prefers-reduced-motion: reduce users often want to eliminate ALL animation delays for workflow efficiency. Some users (*) who disable animations are seeking immediate state changes without any temporal delays, not just avoiding motion-based effects. Consider preserving the previous behaviour of respecting the animation preference for fade effects as well.

Also, this approach is not idiomatic for Windows (and reportedly Android). Turning off Animation Effects in Windows settings does not change system menu pop-up effects from sliding to fading, but effectively makes all pop-ups appear instantaneously upon activation.

For now I've used a userChrome.css hotfix to get what I expect and want, but I'd really like to advocate to make this behaviour the default.

Or is there any other (planned) way to tell the Firefox chrome to skip all unnecessary transitions altogether, and follow the OS approach?

(*) Yes, here I am selfishly speaking for myself; the older I am, the more annoying all effects become for me, sadly, so getting the effect of bug 1965691 after update to 140.0b7 made me do all this.

Comment 1

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 1965691, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Well, prefers-reduced-motion is about motion, and opacity transitions clearly aren't motion. There's the question perhaps of whether we should have a more fine-grained setting to reflect Windows' setting...

Comment 3

[Michal Čaplygin [:myf]]

Thanks for looking into it! Personally, I'd be all in favour to going back to the original philosophy of the CSS and having means for expressing prefers-transparency, -roundness, -transition-duration, -blur-radius, -transform-effects (etc etc) that I would be able to all set to zero with the mean to make them non-negotiable and get snappy and clear UIs everywhere, but that's either wishful thinking or for a specifications for years to come.

Back to the initial practical suggestion that should presumably be actionable right now:

take the "reduced motion" from the OS as a clear signal to ditch all chrome visual transition effects altogether
(and don't overthink it waiting for some potential development in the future)

Look at these super quick "parity" tests:

Testcase 01

STR:

• Open %application%,
• trigger some pop-up menu, usually marked as ⋯/ ⋮ / ≡ / ⌵ / ⊽,
• and observe the effect with and without OS animations enabled.

Test conducted on Widows 11 with applications: Google Chrome 135, Microsoft Edge 137, Firefox 140.0b7, Microsoft Teams 25094, Microsoft Windows Notepad 11.2503, Microsoft OneNote (Office16)

Results on Widows 11

Browser	Animations enabled	Animations disabled
Chrome ⋮	Fade	Instant
Edge ⋯	Instant	Instant
Firefox 140.0b7 ≡	Slide-fade	Fade ⚠
Teams ⌵	Slide-fade	Instant
Notepad ⌵	Slide-fade	Instant
OneNote ⊽	Slide	Instant

I think the outlier is clear here. Do we really want to stand out in this?

Comment 4

[Michal Čaplygin [:myf]]

Well, prefers-reduced-motion is about motion, and opacity transitions clearly aren't motion.

N.B., from the user's perspective, the OS setting that is currently translated to and signalled through the prefer-reduced-motion under the hood on Windows has a visual user-facing label on the surface literally: Animation effects.

It does seem safe to assume that regular user setting Animation effects to Off will do so NOT with an intention to get rid of motion exclusively and keeping opacity and blur effects intact, but rather to, well, to disable all animation effects altogether. Doesn't it?

I agree that the situation is not ideal -- for example the preceding setting at the same Windows preferences page is Transparency effects and it does not seem to be channelled via prefers-reduced-transparency at all -- but the current state when this "Animation effects" pref serves as a proxy for more than one thing seems like the best pragmatical solution at this point.

Comment 5

[Michal Čaplygin [:myf]]

Attachment: Animation effects On/Off toggle inside MS Windows 11 Settings - Accessibility - Visual effects

Comment 6

[Stephen Thompson [:sthompson]]

:morgan Is prefers-reduced-motion the right indicator to use for opacity/fade animations? Or is there another property? Should there be a new media query, or is there an existing accessibility feature available in the codebase? Should that be exposed to CSS?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Fwiw on macos reduces motion does not prevent fading animations. So this I think would need a more subtle media query

Comment 8

[Michal Čaplygin [:myf]]

on MacOS reduce motion does not prevent fading animations [of system roll-down menus (presumably(?))]

Thanks, I was curious about this but have not managed to reach anyone with the system to try it for me. (That's why I've used the "win" component category here, because I wasn't sure about other systems and didn't want to imply that my suggestion is for all them.)

So I guess the suggestion to follow "Disabled effects" outcomes closely on each respective system holds: if fading feels "native" for MacOS with effects turned off, so be it.

I hope that I have demonstrated sufficiently that for Windows instant transitions are way to go to feel "native" when effects are turned off.

(Personally, I wouldn't mind removing all chrome effects even for the "no-preference / effects ON" case, like Edge currently does, since I see little to no benefit in most of them, but clearly consistency with the rest of the OS is still the best approach.)

Comment 9

[Alex Cornestean]

Hello,

I believe I reproduced the issue on the latest Nightly (141.0a1/20250612214230) and Beta (140.0b8/20250611090503) under Windows 11.

Turning off “Animation effects” in the OS does not seem to eliminate the fading when opening/closing the Firefox app menu (which is the pop-up menu I checked) as compared to the app menu on Chrome, under the same conditions.

On Firefox Release (139.0.4/20250609112858) the issue does not appear to exist, the app menu instantly opening/closing.

Comment 10

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1965691

Comment 11

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1965691

Comment 14

[Kelly Cochrane [:kcochrane]]

:ayeddi, do you have any thoughts on this?

Comment 15

[Dianna Smith [:diannaS]]

this doesnt look like a regression at this point, removing tracking flags.

Comment 16

[Michal Čaplygin [:myf]]

For potential passers-by, since the chance of this issue being addressed seems increasingly unlikely:

Workaround: userChrome.css

In brief (⁂): • enable toolkit.legacyUserProfileCustomizations.stylesheets in about:config, • locate your profile folder, • create a chrome\userChrome.css folder\file there, • put the following CSS in it, • and restart the browser.

@media (prefers-reduced-motion: reduce) {
  .animatable-menupopup,
  panel[type="arrow"] {
    transition: none !important;
  }
}

(⁂) More verbose visual guide on how to set up and use userChrome in the form of a formerly-Twitter thread.

---

// It's a sad sight how Firefox's defaults progressively diverge from the original lean and responsive browser suitable for power-users, and how the list of customisations and preference toggles necessary to keep the former ergonomics continues to grow.

Comment 17

[Michal Čaplygin [:myf]]

Considering increasing number of duplicates asking for the same change, changing the title to more assertive wording removing the "Consider" part and distilling main considerations here:

To reiterate

At this point we have quite clear (be it small and anecdotal) evidence regarding attitude of the users who are turning off OS animation effects (let's call them "OGs") to the subtle transition effects introduced by the change that was allegedly »not a regression« (let's call them "unsolicited transitions").

1. There is absolutely no evidence that OGs benefit from the unsolicited transitions whatsoever. Please go forth and prove me wrong.
2. On the contrary, there is clear evidence OGs despise the unsolicited transitions. Just look at the dupes.
3. There is currently no better technical way for the OGs to communicate their preference than through the "prefers-reduced-motion", what is admittedly just a "proxy" and perhaps "misuse" from the strict WCAG standpoint, but it is unlikely some better hatch will emerge soon.

What could possibly ho wrong?

1. Requested change merely restores the state how the things used to be, and since there does not seem to be any issue asking for introduction of the unsolicited transitions, we can assume there will be no backlash.
2. I can imagine that some MacOS enthusiast could argue for aligning effects with the rest of the OS, but I think that the more important question here is whether there actually are any MacOS OGs who would agree with that.

What next

I suggest really returning to the no-transition snappiness of all UI interactions in the "no-effects OS mode" (ergo in the prefersReducedMotion mode) is the way to go here. If you'd like to make other more fine-grained control instead, consider making separate proposal issue for that. But I doubt that inventing and implementing the extra "hatch" for this is worth the effort at this point.

Comment 18

[Morgan Reschenberg [:morgan]]

(In reply to Stephen Thompson [:sthompson] from comment #6)

:morgan Is prefers-reduced-motion the right indicator to use for opacity/fade animations? Or is there another property? Should there be a new media query, or is there an existing accessibility feature available in the codebase? Should that be exposed to CSS?

As emilio said above: macos reduces motion does not prevent fading animations.

Barring a better alternative (there isn't a more specific query that exists right now) I think it's okay to use prefers-reduced-motion.

Comment 19

[Michal Čaplygin [:myf]]

So the résumé is, that it is fine to sprinkle fade-in and fade-out effects into UI on all platforms (*), right?

Do I understand it correctly?

---

(*) even on systems, where system-wide "animations off" setting makes all other UI element transitions in all other software instant, and even for users, who set that preference not "just" because they suffer from some health condition, but who set that preference simply because they prefer instant UI element transitions

Comment 20

[Nick Rishel [:nrishel]]

Given prior discussion this sounds more like a themes issue than a11y, kick back to General if I'm off base.

Comment 21

[Michal Čaplygin [:myf]]

Reduced transparency AND motion

Can we at least discuss idea that the combination of prefers-reduced-transparency and prefers-reduced-motion would be (finally) interpreted as a clear signal of user's intent to never encounter anything moving or semi-transparent, not event for a very brief-yet-observable period of time?

From a quick test, chrome stylesheets do not even need turning the layout.css.prefers-reduced-transparency.enabled on, and happily read the system preference already even in ESR now (*), so tactically placed quick and dirty snippet like

@media (prefers-reduced-transparency) and (prefers-reduced-motion) {
  *|* {
    transition-duration: 1ms !important;
    animation-duration: 1ms !important;
    border-radius: 0 !important;
  }
}

does 116% of the desired outcome for me.

Or can you propose and implement any better and more intuitive mechanism for users to get to similar outcome? Considering all dupes, the demand is really there…

---

(*) Not sure if I tested poorly last year and it was available for chrome back then, or if it is recent addition…

Comment 23

[Michal Čaplygin [:myf]]

From the bug 2076606:

We've not been super consistent on whether [to] treat opacity as motion I guess.
Imho an opacity animation isn't quite motion and maybe needs a different opt out. But I know that opt out currently doesn't exist... Let me page that back in, I don't think I mind just putting the whole animation inside the conditional.

Emilio, with all due respect to your immeasurable accumulated positive contributions to the project, please just revert the change and admit for once that your "little improvement" was the wrong move at the wrong time in this particular case. Evidence of demonstrably annoyed users is piling up, and waiting for a perfect solution would obviously just prolong the suffering of the annoyed group (presumably just a minority, but still relevant), while it would bring zero benefit for the rest. Even the fact that the "rest" is really the "majority", while somewhat intuitive, remains unproven. Personally, I am really curious to see a single user, even anecdotally, who prefers "no motion" and actually enjoys the fades introduced in bug 1965691. My hunch is that there is none, actually. I would expect such research to precede any user-facing change in the codebase, but I understand that the budget here does not allow for such a luxury.

I haven't seen any hard, substantiated evidence here (or elsewhere) proving that sneaking visual effects into systems with disabled visual effects actually helps anyone. All the arguments here were "look at macOS" and "well, we think fades are not motion", plus a lukewarm decision to keep the change, just because. If I saw such an argument coming from an external consultant, I'd call it hand-waving at best, and maliciously compliat at worst.

To give, yet again, the perspective of a "no-effects-preferring" user, consider that any delay postponing the moment you can visually process and interact with content is perceived as a nuisance. Those few milliseconds when the menu is blended with whatever the page content displays at the moment just increase the subjectively perceived effort imposed on such a user (as well as computing demands, while we are at it; disabling animations is often done in low-power modes). There may be studies proving that the objective processing time for humans is not affected by this kind of very brief effect, but that would not disprove the other points presented here.

It wasn't broken, and it needed no "improvement", really.

Comment 24

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1971509 - Disable panel opacity transition on non-mac when reduced motion is enabled. r=#theme

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/85b95fd9647e
https://hg.mozilla.org/integration/autoland/rev/506ff54f6811
Disable panel opacity transition on non-mac when reduced motion is enabled. r=desktop-theme-reviewers,dao

Comment 26

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/506ff54f6811

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for the Fx159 relnotes? If so, set the relnote-firefox flag to "?"
https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Possible wording:

Fixed menus and panels fading in on Windows and Linux when animation effects are turned off in the operating system.

Comment 28

[Emilio Cobos Álvarez [:emilio]]

Sure, WFM.

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]: no
[Suggested wording]: Fixed menus and panels fading in on Windows and Linux when animation effects are turned off in the operating system.
[Links (documentation, blog post, etc)]: This bug?

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx159 relnotes.

Comment 30

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (159.0a1/20261004215034) under Windows 11 and Ubuntu 25.10.

Having turned off “Animation effects” in the OS, I can no longer perceive any fading when opening/closing menus and popups.