Closed Bug 1431237 Opened 3 years ago Closed 4 months ago

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

Categories

(Firefox :: Theme, defect, P3)

57 Branch
defect
Points:
2

Tracking

()

VERIFIED FIXED
Firefox 80
Iteration:
80.1 - June 29 - July 12
Tracking Status
firefox80 --- fixed

People

(Reporter: erwinm, Assigned: dao)

References

(Blocks 4 open bugs)

Details

(Keywords: access, perf-alert)

Attachments

(3 files)

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.
Component: Untriaged → Theme
Not sure why this animation would be more prone to causing migraine than the old one. This might need some UX research.
Blocks: 1352119
Keywords: access
Priority: -- → P3
Summary: Can't block tab loading animation in 57 → Can't block tab loading animation in 57 (animation causes eye strain?)
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
See Also: → 1446713
Depends on: 1352069

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.

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.

Duplicate of this bug: 1558159
Duplicate of this bug: 1446713
Blocks: 1478597
See Also: 1446713

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.

Flags: needinfo?(mverdi)
Keywords: blocked-ux
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Iteration: --- → 79.1 - June 1 - June 14
Points: --- → 2
Iteration: 79.1 - June 1 - June 14 → 79.2 - June 15 - June 28
Iteration: 79.2 - June 15 - June 28 → 80.1 - June 29 - July 12
Flags: needinfo?(mverdi)
Keywords: blocked-ux
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1843db44a57c
Implement static loading icon. r=jaws
Blocks: 1650028
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 80
Depends on: 1650521
Blocks: 1650521
No longer depends on: 1650521
Blocks: 1650704

== 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

Keywords: perf-alert

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.

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.

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

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.

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

Can reporter confirm this is now "fixed"?

If not, should it be "WONTFIX"?

Flags: needinfo?(erwinm)

This is fixed.

Status: RESOLVED → VERIFIED
Flags: needinfo?(erwinm)

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

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

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.

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

See Also: → 1661666

I can confirm that it works in 80.

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