Open Bug 1478597 Opened 2 years ago Updated 6 months ago

Remove toolkit.cosmeticAnimations.enabled preference in favor of prefers-reduced-motion media query

Categories

(Toolkit :: General, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: dao, Unassigned, Mentored, NeedInfo)

References

(Blocks 1 open bug)

Details

The prefers-reduced-motion media query reflects OS settings and users can override it with the ui.prefersReducedMotion pref.
Duplicate of this bug: 1484348
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 controls 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

(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
You need to log in before you can comment on or make changes to this bug.