Open Bug 1478597 Opened 6 years ago Updated 1 year ago

[meta] Respect prefers-reduced-motion for UI animations

Categories

(Firefox :: General, enhancement, P3)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

People

(Reporter: dao, Unassigned)

References

(Depends on 6 open bugs, Blocks 1 open bug)

Details

(Keywords: access, meta)

The prefers-reduced-motion media query reflects OS settings and users can override it with the ui.prefersReducedMotion pref.
Maybe a good mentored bug?
Priority: -- → P3
Yeah.
Mentor: dao+bmo
Summary: Remove toolkit.cosmeticAnimations.enabled in favor of prefers-reduced-motion media query → Remove toolkit.cosmeticAnimations.enabled preference in favor of prefers-reduced-motion media query
Hi, sounds like an interesting task. I would like to give it a try. If that's okay I need some hints: 1. I've already taken a quick look at the file /browser/base/content/browser-contentblocking.js I could do something like the following: ``` this.updateAnimationsEnabled = () => { this.iconBox.toggleAttribute("animationsenabled", Services.prefs.getBoolPref(this.PREF_ANIMATIONS_ENABLED, false)); }; ``` could be changed to: ``` this.updateAnimationsEnabled = () => { const win = this.iconBox.ownerDocument.defaultView; const reducedMotion = win.matchMedia("(prefers-reduced-motion)").matches; this.iconBox.toggleAttribute("animationsenabled", !reducedMotion); }; ``` Inspired by bug 1460862. This works. But what's about the following? Services.prefs.addObserver(this.PREF_ANIMATIONS_ENABLED, this.updateAnimationsEnabled); and Services.prefs.removeObserver(this.PREF_ANIMATIONS_ENABLED, this.updateAnimationsEnabled); I guess it's to react to preference changes at runtime. Is there something comparable to detect changes of the prefers-reduced-motion OS setting? 2. /browser/components/customizableui/CustomizeMode.jsm: There is the following code at the top: ``` XPCOMUtils.defineLazyPreferenceGetter(this, "gCosmeticAnimationsEnabled", "toolkit.cosmeticAnimations.enabled"); ``` And then gCosmeticAnimationsEnabled is used within the file. For a case like this what is the preferred way to detect and set the prefers-reduced-motion value? 3. Do you have any other useful information to implement these changes? I didn't look in all files, there will probably be more questions if / once I work on this, but it's enough for now to get started. ;)
(In reply to Sören Hentzschel from comment #4) > I guess it's to react to preference changes at runtime. Is there something > comparable to detect changes of the prefers-reduced-motion OS setting? Sure. MediaQueryList has onchange handler [1] so that you can detect the changes. Of course you can use addEventListener too something like this; window.matchMedia('(prefers-reduced-motion: reduce)').addEventListener('change', event => { // do something. }); I am not sure which way is preferable in browser code. [1] https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/onchange
Thank you for your answer! Unfortunately this doesn't work. I tested on macOS Mojave Public Beta. Firefox detects changes only after a restart of Firefox. To verify this theory I created a test HTML file only with the following code: ``` <html> <head> </head> <body> <script> const reducedMotion = window.matchMedia("(prefers-reduced-motion: reduce)").matches; console.log(reducedMotion); window.matchMedia('(prefers-reduced-motion)').addEventListener('change', event => { console.log(event); }); </script> </body> </html> ``` The code within the addEventListener block wasn't executed at all. At least the first console statement should log the correct value after changing the OS preference and then reloading the HTML file. But even after changing the OS preference and reloading the HTML file the old value was still logged. After a restart of Firefox the new value was logged. This explains why the onchange listener doesn't work - because Firefox needs a restart to get the new value. So maybe a platform bug?
Yes, it's bug 1486971. I should have noted it. :/
A workaround is to use non-E10S without any other firefox instances.
Thank you. For a HTML file the workaround works. But the Firefox frontend still needs a restart to detect a change of the setting. I will wait until bug 1486971 has been fixed and then test again.
Depends on: 1486971
Blocks: mojave
Depends on: 1492284
After some discussion with the accessibility team (eejay), and reading https://webkit.org/blog/7551/responsive-design-for-motion/ I'm no longer sure this makes sense. The kind of animations covered by the toolkit.cosmeticAnimations.enabled preference can't really be described as "vestibular triggers"; for the most part they are momentary, subtle motions over small areas of the screen. That doesn't align with the intention of prefers-reduced-motion which seems to be for disabling larger, dramatic and/or looping animations. I respect that many users might prefer to turn off animations for their own reasons, but I'm in favor of closing this bug as WONTFIX and if necessary opening new bugs where we can make a case by case assessment of what the right level of user control should be, and if it makes sense to enable a particular animation based on prefers-reduced-motion.
I was under the impression that we added toolkit.cosmeticAnimations.enabled primarily to address "motion sickness" concerns. With that in mind toolkit.cosmeticAnimations.enabled 1) is probably badly named and 2) might currently control animations it shouldn't control, but that seems orthogonal to this bug...
Yeah, I agree. It seems 'cosmetic' doesn't explain what kind of animations are cosmetic actually. Anyway FWIW I am referring from the spec [1]; they prefer an interface that minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed. It seem to me we can replace the preference with the media query. [1] https://drafts.csswg.org/mediaqueries-5/#valdef-media-prefers-reduced-motion-reduce
(In reply to Hiroyuki Ikezoe (:hiro) from comment #12) > Yeah, I agree. It seems 'cosmetic' doesn't explain what kind of animations > are cosmetic actually. > > Anyway FWIW I am referring from the spec [1]; > > they prefer an interface that minimizes the amount of movement or > animation, preferably to the point where all non-essential movement is > removed. > > [1] > https://drafts.csswg.org/mediaqueries-5/#valdef-media-prefers-reduced-motion- > reduce Fair enough. Of the motions controlled by this pref, only the full screen transitions seem to meet the vestibular trigger definition. Perhaps the content blocking one due to its relative frequency. I guess its a question of "needs reduced motion" vs. "prefers reduced motion". I don't think it would be bad or wrong to make this change, but as its not a pressing accessibility bug we should be clear about who benefits. That's why I think this is best addressed case by case rather than a batch change for all toolkit.cosmeticAnimations.enabled consumers.
See Also: → 1520641
See Also: → 1540174

(In reply to Sören Hentzschel from comment #9)

Thank you. For a HTML file the workaround works. But the Firefox frontend
still needs a restart to detect a change of the setting. I will wait until
bug 1486971 has been fixed and then test again.

Still want to look into this?

Flags: needinfo?(soeren.hentzschel)
Depends on: 1584273
Depends on: 1629953
Flags: needinfo?(soeren.hentzschel)
Depends on: 1630918
Mentor: dao+bmo
Keywords: meta
Summary: Remove toolkit.cosmeticAnimations.enabled preference in favor of prefers-reduced-motion media query → [meta] Remove toolkit.cosmeticAnimations.enabled preference in favor of prefers-reduced-motion media query
Depends on: 1631438
Depends on: 1631734
Depends on: 1632166
Depends on: 1632176
Depends on: 1520641
See Also: 1520641 →
Depends on: 1633635
Keywords: access
Depends on: 1634861
Depends on: 1635095
Depends on: 1635419
Depends on: 1635475
Depends on: 1636057
Summary: [meta] Remove toolkit.cosmeticAnimations.enabled preference in favor of prefers-reduced-motion media query → [meta] Respect prefers-reduced-motion for UI animations and remove toolkit.cosmeticAnimations.enabled preference
Depends on: 1636112
Depends on: 1638030
Depends on: 1431237
Depends on: 1638064
Depends on: 1638066
Depends on: 1638067
Depends on: 1638068

Do you think this can also be fixed https://bugzilla.mozilla.org/show_bug.cgi?id=649671 ("expand" after mouse out)? There is also animation when many tabs are open (full tab bar) and new one is opened at the end.

Depends on: 1417079
Depends on: 1640500
Depends on: 1640501
Summary: [meta] Respect prefers-reduced-motion for UI animations and remove toolkit.cosmeticAnimations.enabled preference → [meta] Respect prefers-reduced-motion for UI animations
Severity: normal → S3
Product: Toolkit → Firefox
Depends on: 1640502
Depends on: 1503678
Depends on: 1585608

  1. prefers-reduced-motion is ambiguous. While I believe the choice of words comes from the implementation on iOS and macOS, where the system preference is indeed Reduce Motion, the preference in Windows is worded "Show animation in Windows" which does appear to mean all or nothing, at least syntactically, whether or not it is meant to be taken literally. iOS has since added a second preference to replace menu motion with fade-in, but that has not propagated across systems yet.

  2. vestibular disorder is not only triggered by full-screen motion. I can experience it with smaller areas if they are in my area of focus. That said, they tend to be relatively larger areas (at least for me).

  3. It's not just about vestibular disorder. Small areas of animation can be a trigger for hypervigilance.

Depends on: 1642323
Depends on: 1643167
Depends on: 1643606
Depends on: 1629303
Depends on: 1540174
See Also: 1540174 →
Depends on: 1650028
Depends on: 111373
Depends on: 1696360
Depends on: 1714243
You need to log in before you can comment on or make changes to this bug.