Open Bug 456620 Opened 16 years ago Updated 2 years ago

Allow users to turn off transition effects

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: aaronlev, Unassigned)

References

Details

(Keywords: access) 

This is a real problem for some people that I've documented here:
http://accessgarage.wordpress.com/2008/09/23/motion-sickness-and-transition-effects/

As documented in that entry it's also a section 508 violation and UAAG issue.

The user needs to be able to configure this so it's off. If there is a platform pref we should use it. I'm not aware of any such pref in the platforms we're on but I haven't looked at it much. 

When it's configured to be off, we can just make the slide effect so fast that it's not noticable as a transition. I know of at least on place that we need to do this:
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/notification.xml#188

The VPAT needs to be updated as well to mention the issue.
Do you consider the smooth scrolling in the tab bar a transition?

Do we need a global pref or a pref per instance?
How about the preferences window resizing on Mac when you switch panes?
the appearance tab in windows xp's display control panel has an effects button, which leads to [x] Use the following transition effect for menus and tooltips

and [x] show window contents while dragging.

i don't remember what the defaults are, but for me, the latter is unchecked, this seems to be something close to a global pref which i think would mean "i might get motion sickness".

smooth scrolling in the tab bar is definitely a transition, and yes a global pref is probably wanted. making people who get sick toggle multiple prefs is not nice.
Dao, we just need a global pref.

Timeless, that makes sense to me. Any kind of smooth scrolling or transition effect could be turned off from XP's
[x] Use the following transition effect for menus and tooltips

Jesse, I don't have a Mac. Could you be more specific what the pref is there?
Aaron, on Mac when you switch panes in the preference window we resize the window to the size of the new pane, and do so in a smooth transition-y way.  It sounds like we'd want to not resize it at all or something, with this pref set....
(In reply to comment #4)
The pref is browser.preferences.animateFadeIn and works on Windows as well (it just defaults to |false| on non-Mac platforms).
Making the transition happen immediately rather than over a period of 500ms fixes this accessibility problem, right?
Jesse, that's correct.
(In reply to comment #4)
> Timeless, that makes sense to me. Any kind of smooth scrolling or transition
> effect could be turned off from XP's
> [x] Use the following transition effect for menus and tooltips

I know I've turned that off previously, because I didn't see its point, not because it was a problem for me. I wouldn't want to lose smooth scrolling at the same time.
For the accessibility fix, I think we want some kind of global setting.
Some people have suggested we use CSS or SVG to do these things.

I just want to point out one more alternative.
One no animation is set, any element (XUL, HTML, etc). that gets a change for x, y, width or height gets put into a queue, with the desired new coordinates. If that element is already in the queue, then the coordinates are just updated instead. Putting something in the queue starts or resets a timer. Once the timer hits .25 seconds or something like that, then the queue is emptied and all the positions are updated.

I suppose the problem with that is that script be saying elt.x +=10 on a short timer though, so the reported position needs to be updated whereas the shown position isn't yet. In any case, it seems possible to do this with some clever coding.

The good thing is that it would fix HTML that does this as well, without expecting them to use some nonstandard CSS that doesn't work in other browsers.
Blocks: 466286
Hi, I'm not sure if anyone noticed the first comment from someone named Kurt at the mentioned blog post, so it's better to be said twice rather than never:

"Just show the bar over the page content. In other words, don’t slide the content downwards to make room for the bar. This can either be done by just having the bar show on top with not fade in effect or have a fade in effect."

I second his opinion - even for a normal person without motion sickness it's still very annoying and unconfortable the page content moving to make space for the bar!
Forgot to mention that the same annoying effect can be obtained when going full screen and moving the mouse to uppper are to switch tabs - the page content slides down to make space for the tab bar and navigation bar. I didn't notice this until these days when i'm browsing in full screen.
As more transition effects switch to being implemented using CSS transitions (e.g., bug 521890), adding a user style sheet with the rule "* { -moz-transition: none ! important }" will become more effective at disabling them.
I don't think a "-moz-transition: none" user stylesheet will end up being a very good solution... Since transitions fire transitionend events which the page may be expecting, disabling transitions like this could cause things to break.

3 ideas that come to mind:

1) Transition duration / delays are clamped to 0, so all transitions happen immediately. Likely to break things which don't expect events to fire immediately or rely on the duration to make something work (eg, consider a scrolling news ticker implemented by a transition sliding a long line of text through a viewport).

2) Transitions run with the expected duration / delay, but the style changes are only updated at the end of a transition. This is less likely to break a page, but has some usability issues in that UI elements could appear slow to respond because their intermediate transitions are missing.

3) Transitions run with the expected duration / delay, but style change frequency is clamped to a slower update rate. Smooth transitions become a sequence of discrete steps. But I'm assuming that users can select a rate that's slow enough to avoid triggering motion-sickness, flashing sensitivity, etc.
Depends on: 422260
For the love of all that is holy, just make it a damn feature in the preferences of firefox. This bug is almost 2 years old and the elitist approach of zooming in on every detail before making a decision (or telling the user to alter firefox's behaviour in various other ways) helps no one.

Edit -> Preferences -> Content -> Disable animations.

You may call it transitions internally but the normal world will call it an animation, because it moves.
See Also: → 984589
Mar(In reply to Marckus M. van Dijk from comment #15)
> For the love of all that is holy, just make it a damn feature in the
> preferences of firefox. This bug is almost 2 years old and the elitist
> approach of zooming in on every detail before making a decision (or telling
> the user to alter firefox's behaviour in various other ways) helps no one.
> 
> Edit -> Preferences -> Content -> Disable animations.
> 
> You may call it transitions internally but the normal world will call it an
> animation, because it moves.

While it may seem obvious, there are a whole host of CSS transitions that you probably aren't even aware off. Doorhangers appear not-quite-instantly, the urlbar dropdown expands during a fraction of a second to prevent jerkiness as new results come in. Should all these be switched off by the same preference that controls the more gross "animations" and "smooth" effects? They are certainly unpleasant on some low-power machines but the alternative is quite jarring on more mainstream hardware.

I would like to see something though and I actually have most, possibly all, CSS transitions disabled on one machine because the graphics card doesn't do them well. As more and more transitions are added effectively with every new feature, it seems to get more important for this preference to prevent poor (sic!) people's machines literally shuddering to a halt.
Please consider adding a separate option for those UI transition effects. I understand that some users of mainstream hardware may prefer to disable just non-UI effects, and that's probably a good way to separate this into two options.

(Unfortunately, in all my time as a user of Mozilla software, I have never met such mainstream hardware...)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.