1431237 - Can't block tab loading animation in 57 (animation causes eye strain?)

Status: VERIFIED FIXED

(Firefox :: Theme, defect, P3)

Description

[MarjaE]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

I tried Firefox 57. I had a number of animation-blocking about:config fixes, and add-ons.


Actual results:

I got hit by the new tab loading animation. I don't like the migraines. I need to be able to block animation. Somehow toolkit.cosmeticanimations.enabled false doesn't block this cosmetic animation.


Expected results:

First, toolkit.cosmeticanimations.enabled false, or other about:config fixes, should block this animation.

Second, a regular preference should be available to protect against all this animation.

Comment 1

[Dão Gottwald [:dao]]

Not sure why this animation would be more prone to causing migraine than the old one. This might need some UX research.

Comment 2

[MarjaE]

If there was an old pain/animation, I have long since blocked it. I can't block the new pain/animation.

Also, it causes migraines, not just eye strain.

Comment 3

[Sam Foster [:sfoster] (he/him)]

The tab loading animation doesn't fall into the same category as the other animations covered by the toolkit.cosmeticanimations pref: it is not just cosmetic, its communicating information about what is going on with that tab. That said, I have heard complaints from a few people about this particular animation - as bugs filed, social media and in person. There should be *some* practical way to replace this. Perhaps an extension, theme or another pref. But we can't implement that until we understand the problem better and come up with an alternative solution - a way to communicate requesting and loading state for a tab. 

I'm making this bug "new" rather than unconfirmed as the reporter is correct - there isn't a good way to block or change this experience. But until we have a plan for what to do about it, this isn't really actionable yet.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

A Webextension Theme could set the tab-loading-fill to transparent which would effectively remove it, or it could use a color with a very low alpha value which wouldn't be as visible.

Comment 5

[Graham Perrin]

FWIW this userChrome.css seems to work, for me, with Firefox 64.0.2 on FreeBSD-CURRENT:

.tabbrowser-tab .tab-throbber,
.tabbrowser-tab .tab-icon-image{
  display: none !important;
  visibility: collapse !important;
}

Source: https://github.com/Aris-t2/CustomCSSforFx/issues/98#issuecomment-354144672 (2017-12-27) under 'Favicon Remover For All Tabs · Issue #98 · Aris-t2/CustomCSSforFx'.

In the context of this bug 1431237 it's overkill (more than just a block of animation), but it might be useful to followers of the bug.

Comment 6

[Graham Perrin]

Re: comment 4 under Tab loading throbber is not accessible to users sensitive to changes in visual motion

Before my previous comment, I was aware that a userChrome.css approach might not work at Firefox start time.

Now, unfortunately, in addition it seems that:

• userChrome.css sometimes fails to work whilst Firefox runs (long after a successful start).

This may be most likely to bite when, for example, reopening a closed tab. It smells to me like a side effect of a separate bug but I can not find a match.

Comment 9

[Dão Gottwald [:dao]]

I think we should use a static loading icon for users who have opted into reducing motion. verdi, could you get me such an icon? I was thinking an hour glass icon would work well.

Comment 10

[Dão Gottwald [:dao]]

Attachment: Bug 1431237 - Implement static loading icon.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1843db44a57c
Implement static loading icon. r=jaws

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/1843db44a57c

Comment 13

[Florin Strugariu [:Bebe]]

== Change summary for alert #26507 (as of Tue, 14 Jul 2020 16:49:12 GMT) ==

Improvements:

3% Images linux1804-64-shippable-qr opt 5,718,041.51 -> 5,550,196.76

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=26507

Comment 14

[lexlexlex]

I'm using Windows 7. I never clicked "Control Panel > Ease of Access > Make the computer easier to see > Turn off all unnecessary animations (when possible)" but I found it was enabled after researching why I now see an ugly hourglass icon instead of the loading pulse that indicates loading. Windows toggles this "ease of access" setting when toggling transition animations off, which is all I did. I did not toggle this "ease of access" setting myself.

The reason I disabled these transition animations is this: I don't mind animations that don't cause delays in my computer usage, but I do mind transition animations that aren't instant. This is because the earlier that a transition is finished, the earlier I can use the next UI that is present after the transition on my computer. This has nothing to do with my ability to see. It's actually the opposite. I just want my time to not be wasted by unnecessary transition animations. Disabling these transition-specific animations in Windows is expected to have no effect on whether non-transition animations in my web browser play.

I propose that transition animations and animations that don't affect transitions be treated differently.

For example, a looping animation on an otherwise-static website is not the same as a page slowly fading from one page to the next. I would leave the former enabled and prefer it to never be disabled, while I would try to find a way to disable the latter, at least if it's something I expect to see often in the future.

In the case of this tab icon animation, the animation can start and stop instantly, and its presence does not prevent the instant closing of a tab (for which I have transition animations disabled too). I'm using the following CSS code I wrote for instant transitions via userChrome.css:

* {
	animation-delay: 0ms !important;
	animation-duration: 0ms !important;
	transition-delay: 0ms !important;
	transition-duration: 1ms !important;
	transition-property: none;
}```

By the way, transition-duration has to be 1ms instead of 0ms to prevent submenu entries, such as those in the "Web Developer" submenu, from breaking (being unclickable).  I'm not sure if there's a bug report for that.

For now, I've added ```ui.prefersReducedMotion``` set to ```1``` in about:config to override the new behavior.  Thank you for providing that option.

Bottom line: I don't prefer reduced motion except in the case of forcing me to wait for transitions, so the change in https://hg.mozilla.org/mozilla-central/rev/1843db44a57c has erroneously captured me as the target audience.  Transition animations and non-transition animations must be treated separately.

Thank you for development.  I love Firefox and I am extremely grateful for its continued support.  I appreciate Firefox developers always keeping options in mind and considering as much as possible when deciding on default behavior.

Comment 15

[lexlexlex]

It appears this Bugzilla instance has an issue rendering markdown. Apologies for not previewing my last post before posting. I hope that can be fixed, causing my post to be rendered as intended and expected.

Comment 16

[Dão Gottwald [:dao]]

(In reply to lexlexlex from comment #14)

I'm using Windows 7. I never clicked "Control Panel > Ease of Access > Make the computer easier to see > Turn off all unnecessary animations (when possible)" but I found it was enabled after researching why I now see an ugly hourglass icon instead of the loading pulse that indicates loading. Windows toggles this "ease of access" setting when toggling transition animations off, which is all I did. I did not toggle this "ease of access" setting myself.

Bottom line: I don't prefer reduced motion except in the case of forcing me to wait for transitions, so the change in https://hg.mozilla.org/mozilla-central/rev/1843db44a57c has erroneously captured me as the target audience. Transition animations and non-transition animations must be treated separately.

This sounds like a problem within Windows 7 rather than Firefox. How would we tell you apart from users who explicitly disabled unnecessary animations when Windows 7 lumps the two preferences together?

Also note that Microsoft doesn't support Windows 7 anymore. Presumably Windows 10 doesn't have this problem.

Comment 17

[lexlexlex]

If it's a problem in Windows 7, it's also a problem in most, if not all, of these OSes' preferences, it seems. Here are some examples from what I know about these preferences that these preferences are for transition animations.

• The gtk-enable-animations preference in GNOME controls whether GUI transition animations play.
• In Windows 10, "Settings > Ease of Access > Display > Show animations in Windows" also controls whether transition animations play.
• In iOS, "Settings > General > Accessibility > Reduce Motion" controls whether the transition animations should zoop or fade. It seems to have no effect on looping or video playback animations anywhere in the OS, from my daily usage of this OS.

Admittedly, I'm not sure what the macOS or Android preferences do. I use those OSes less often.

From what I'm seeing, these preferences selected in this bug report for whether Firefox will show this looping tab icon animation are actually used in their respective OSes for whether or how to show transition animations in those OSes' GUIs. As a result, I believe respecting those for whether to show this looping animation seems erroneous.

Disabling looping or video animations is expected to be another matter entirely, at least from my perspective.

Comment 18

[Dão Gottwald [:dao]]

(In reply to lexlexlex from comment #17)

If it's a problem in Windows 7, it's also a problem in most, if not all, of these OSes' preferences, it seems. Here are some examples from what I know about these preferences that these preferences are for transition animations.

• The gtk-enable-animations preference in GNOME controls whether GUI transition animations play.
• In Windows 10, "Settings > Ease of Access > Display > Show animations in Windows" also controls whether transition animations play.
• In iOS, "Settings > General > Accessibility > Reduce Motion" controls whether the transition animations should zoop or fade. It seems to have no effect on looping or video playback animations anywhere in the OS, from my daily usage of this OS.

None of these preferences seem to claim that they /only/ disable "transition animations", so if you're setting them for that reason you can't really blame the OS nor Firefox...

Comment 19

[Worcester12345]

Can reporter confirm this is now "fixed"?

If not, should it be "WONTFIX"?

Comment 20

[Dão Gottwald [:dao]]

This is fixed.

Comment 21

[lexlexlex]

(In reply to Dão Gottwald [::dao] from comment #18)

(In reply to lexlexlex from comment #17)

If it's a problem in Windows 7, it's also a problem in most, if not all, of these OSes' preferences, it seems. Here are some examples from what I know about these preferences that these preferences are for transition animations.

• The gtk-enable-animations preference in GNOME controls whether GUI transition animations play.
• In Windows 10, "Settings > Ease of Access > Display > Show animations in Windows" also controls whether transition animations play.
• In iOS, "Settings > General > Accessibility > Reduce Motion" controls whether the transition animations should zoop or fade. It seems to have no effect on looping or video playback animations anywhere in the OS, from my daily usage of this OS.

None of these preferences seem to claim that they /only/ disable "transition animations", so if you're setting them for that reason you can't really blame the OS nor Firefox...

There's still a problem here though. What I mean is that those options aren't for disabling video / looping animations. They don't do that. Yet, Firefox is reading them as that. There's a misunderstanding on Firefox's part here.

Comment 22

[MarjaE]

It's not fixed as of Firefox 79, and I've got an awful migraine from checking.

Comment 23

[MarjaE]

And some of us need to protect ourselves from the migraine-inducing animation. Just because most other apps inflict extra pain/animation on users doesn't mean Firefox ought to. Just because they ignore these safety/accessibility options doesn't mean Firefox should ignore readily-available safety/accessibility options.

Up to now I've been using user css to block this. But it's an issue since not everyone is familiar with user css, and because browser problems like this can make it harder to find browser solutions online.

Comment 24

[lexlexlex]

It is confirmed to have the change in Firefox 80. I've confirmed that. I'm not debating that the ability to block looping animations should not be present. I'm just saying that these preferences used to detect the default behavior aren't the right ones.

It seems to me that the more appropriate preference to detect the default behavior here should be image.animation_mode, where the preferences would work this way:

• none: prevent looping animations
• once: loop animations once
• normal: loop animations continuously, until the animations themselves are programmed to stop looping

This preference makes sense to support for this, as it is related to continuous animations, and not transition animations like the ones Firefox 80 is currently using to detect this behavior.

Comment 25

[Worcester12345]

(In reply to Worcester12345 from comment #19)

Can reporter confirm this is now "fixed"?

If not, should it be "WONTFIX"?

(In reply to Dão Gottwald [::dao] from comment #20)

This is fixed.

(In reply to MarjaE from comment #22)

It's not fixed as of Firefox 79, and I've got an awful migraine from checking.

Try version 80, and then report back here. Good luck!

Comment 26

[alvinhochun]

As I understand it from reading the changeset, there is no simple way to re-enable the animated loading icon while having other animations. Is it feasible to override the styles using userChrome.css to get them back, or would there be any better ways?

Comment 27

[Zed]

Attachment: CSS snippet

(In reply to alvinhochun from comment #26)
> As I understand it from reading the changeset, there is no simple way to re-enable the animated loading icon while having other animations. Is it feasible to override the styles using `userChrome.css` to get them back, or would there be any better ways?

I've used the linked CSS tweak in my `userChrome.css` to restore the loading icon when animations are reduced:

`

Comment 28

[Zed]

Attachment: CSS snippet

(In reply to alvinhochun from comment #26)
> As I understand it from reading the changeset, there is no simple way to re-enable the animated loading icon while having other animations. Is it feasible to override the styles using `userChrome.css` to get them back, or would there be any better ways?

I've used the linked CSS tweak in my `userChrome.css` to restore the loading icon when animations are reduced:

`

Comment 29

[Zed]

(In reply to alvinhochun from comment #26)

Is it feasible to override the styles using userChrome.css to get them back, or would there be any better ways?

After updating Firefox Dev to the latest build (80.0b1 & b2) I've noticed too the loading animation getting replaced with the static hourglass. I fail to see the reasoning behind animations and accessibility being treated as a set - one might want to reduce (some) animations without disabling them all, especially useful ones like a loading status indicator. This second category should be included under a separate, more encompassing accessibility trigger.

After spending a while to figure out what exactly prompted the hourglass to appear, I've poked around the CSS changes and used the following CSS tweak in my userChrome.css to restore the loading icon with reduced animations:
https://jsfiddle.net/dpfv3mw4/

PS: The snipped is kinda long for inline inclusion and adding it as attachment to the comment fails with APIError: "Failed to fetch attachment ID [...] from S3: The requested key was not found" (code: 68000)

PS2: Sorry about the disaster above, the attachment kept failing but the form said nothing about my message getting submitted anyway. Someone with the necessary access please delete my previous comments as apparently I cannot (nor edit them). Thanks!

Comment 30

[MarjaE]

I can confirm that it works in 80.