Open Bug 984589 Opened 6 years ago Updated 2 years ago

Doorhanger/panelui menus have animations. There should be an option to disable them completely to appear instantly.

Categories

(Firefox :: Menus, defect)

30 Branch
defect
Not set

Tracking

()

REOPENED

People

(Reporter: u501112, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2810759&p=13416209

I would like to disable the animations of Panel-based menus. They quickly fade downward into view, instead of appearing instantly in place upon clicking. These menus include the Doorhanger notification panels, Downloads panel, Bookmarks panel, site security panel, and the 3 bar menu panel. Sure, this is probably on the order of hundreds of milliseconds, but it is a niggling consistency issue to me when I have menu delays disabled everywhere else in Windows and in Firefox via ui.submenuDelay=0... not to mention the fact that in some rare cases the fade in of the panel is slightly choppy.  Windows and Android both have system settings to disable animations, and Windows can do it at a granular level.  Firefox should be able to do this, too.
OS: Windows 8.1 → All
Hardware: x86_64 → All
Version: 27 Branch → 30 Branch
Component: Untriaged → Menus
Duplicate of this bug: 984585
This wasn't introduced with these panels. The panel animation has been there longer, and has applied to all arrow panels since Firefox 17. See bug 767133.
Sorry, the duplicate was made by mistake during submission. Also, I realize the panel animation has been there longer, but it's especially nagging as more of the core menus of Firefox become arrow panels.
A userChrome could be used to force the opacity of .panel-arrowcontainer to 1, and transform to "none". I just tested that with DOM inspector locally, and that eliminated the animations for me.
I'd settle for an about:config setting if it isn't possible to add an animations/performance tab in the Advanced section of Firefox options.  Everyone is familiar with this, http://i.imgur.com/xgkrw8r.png and as Firefox keeps adding more animations, it might make sense to add something like that (or as an addon/userstyle if devs think integrating too many built-in options is a bad thing.)

Mike Conley, thanks for looking into this. I lack the skills the fill in the gaps of what you did in DOM inspector.  Could you toss together the exact userChrome lines and share it here for me to use in the meantime?  Outside of the addon to move stop/reload to the left of the location bar, the arrow panel animations are the only thing bothering me at this point.
Try:

.panel-arrowcontainer {
  opacity: 1;
  transform: none;
}
Mike Conley: I made a new style in Stylish using just that. It successfully disabled the animation.  However, with that enabled, the bookmarks in the bookmark arrow panel no longer work. Hovering over the bookmarks don't highlight them, and left clicking on them does nothing.  Disabling that makes it work again.  Is there a solution?
(In reply to shiretoko212 from comment #7)
> Mike Conley: I made a new style in Stylish using just that. It successfully
> disabled the animation.  However, with that enabled, the bookmarks in the
> bookmark arrow panel no longer work. Hovering over the bookmarks don't
> highlight them, and left clicking on them does nothing.  Disabling that
> makes it work again.  Is there a solution?

.panel-arrowcontainer {
  opacity: 1;
  transform: none;
  pointer-events: all !important;
}
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks, Tim.  Works now.  I submitted it to userstyles.org via http://userstyles.org/styles/99666/disable-arrow-panel-animations
The submenus of the main menu arrow panel has a delaying slide out animation, specifically, History, Developer, and Help.  Is there a bit of simple CSS to disable that as well?
(In reply to shiretoko212 from comment #10)
> The submenus of the main menu arrow panel has a delaying slide out
> animation, specifically, History, Developer, and Help.  Is there a bit of
> simple CSS to disable that as well?

This CSS will disable all transitions in the Panel Menu, including short background-color transition on some buttons :

>=#PanelUI-popup * {transition:none !important;}

I haven't figured out something more specific (only for subviews), but this css should be enough for you.
(In reply to Tim Nguyen [:ntim] from comment #11)
> (In reply to shiretoko212 from comment #10)
> > The submenus of the main menu arrow panel has a delaying slide out
> > animation, specifically, History, Developer, and Help.  Is there a bit of
> > simple CSS to disable that as well?
> 
> This CSS will disable all transitions in the Panel Menu, including short
> background-color transition on some buttons :
> 
> >=#PanelUI-popup * {transition:none !important;}
> 
> I haven't figured out something more specific (only for subviews), but this
> css should be enough for you.

Woops accidently added the equal sign. Here's the correct code :
#PanelUI-popup * {transition:none !important;}
ntim: Thanks! I updated the style I put up with that, and it works. http://userstyles.org/styles/99666/disable-arrow-panel-animations-v2

Note that as a whole I don't dislike all animations.  The animation of the bookmark star falling into the bookmark menu is awesome and same with the download panel green notification animations.  Informational animations are great.  I only personally dislike animations that perceptually delay displaying interfaces.  That being said, disabling any or all animations in Firefox should be user accessible.
(In reply to shiretoko212 from comment #13)
> ntim: Thanks! I updated the style I put up with that, and it works.
> http://userstyles.org/styles/99666/disable-arrow-panel-animations-v2
> 
> Note that as a whole I don't dislike all animations.  The animation of the
> bookmark star falling into the bookmark menu is awesome and same with the
> download panel green notification animations.  Informational animations are
> great.  I only personally dislike animations that perceptually delay
> displaying interfaces.  That being said, disabling any or all animations in
> Firefox should be user accessible.

I think it feels quite bulky without the animations, plus, by the time you reach the content, the animation would already be finished. That said, I would understand why some people don't like them.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Any reason behind WONTFIXing ? I mean many browser animations can be disabled, I don't know why it shouldn't be the case for the panels and subviews. Especially with the new animation coming soon.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
The latest nightly added another diagonal slide out animation to the history, site identity, downloads, and bookmarks panel menu on open. This happens even with the userscript enabled. Somehow the new animation doesn't apply to the main menu. What additional CSS is required to disable the latest animation now?
(In reply to shiretoko212 from comment #16)
> The latest nightly added another diagonal slide out animation to the
> history, site identity, downloads, and bookmarks panel menu on open. This
> happens even with the userscript enabled. Somehow the new animation doesn't
> apply to the main menu. What additional CSS is required to disable the
> latest animation now?

.panel-arrowcontainer {
  opacity: 1;
  transform: none;
  transition: none !important;
  pointer-events: all !important;
}

Somewhy, UX decided to disable the skew animation from the main menu.
I already tried transition: none !important; as well. It doesn't disable the new animation.  Any other ideas?
transform:none !important;
That doesn't work either.
I used a diff from here to figure out how to disable the new animations: https://bugzilla.mozilla.org/show_bug.cgi?id=610545#c47

Updated the style.  See source for the weirdness required to disable them. http://userstyles.org/styles/99666/disable-arrow-panel-animations-v3
(In reply to shiretoko212 from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101
> Firefox/27.0 (Beta/Release)
> Build ID: 20140212131424
> 
> Steps to reproduce:
> 
> http://forums.mozillazine.org/viewtopic.php?f=23&t=2810759&p=13416209
> 
> I would like to disable the animations of Panel-based menus. They quickly
> fade downward into view, instead of appearing instantly in place upon
> clicking. These menus include the Doorhanger notification panels, Downloads
> panel, Bookmarks panel, site security panel, and the 3 bar menu panel. Sure,
> this is probably on the order of hundreds of milliseconds, but it is a
> niggling consistency issue to me when I have menu delays disabled everywhere
> else in Windows and in Firefox via ui.submenuDelay=0... not to mention the
> fact that in some rare cases the fade in of the panel is slightly choppy. 
> Windows and Android both have system settings to disable animations, and
> Windows can do it at a granular level.  Firefox should be able to do this,
> too.

Thanks for raising this, Shiretoko (did you know "Shiretoko" was our codename for Firefox 3.5?).  It's true that milliseconds matter hugely in interface interactions - a few on either side is the difference between a product that feels sluggish or speedy.  When we designed these animations, we did it knowing there was a tradeoff between visibility and performance, and I'm sure we didn't make perfect decisions!

Really glad you have an - albeit imperfect - way to get this behavior you're looking for in http://userstyles.org/styles/99666/disable-arrow-panel-animations-v3. 

I'm closing this bug because having this level of animation control isn't on our roadmap right now - partially because it's tough to support and partially because there are workarounds for those who want a more granular level of control.  I really understand that this is frustrating, but I hope you feel (like we do) that one of the perks of being open is that these can be tweaked on an existing build.

The choppiness you mentioned is not ok and absolutely something we're trying to fix.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → WONTFIX
Yes, I picked up the handle shiretoko as a tribute to 3.5 and have been using it since those former days.

The following settings exist to control animations within Firefox at the moment in about:config.
browser.tabs.animate
browser.panorama.animate_zoom
general.smoothScroll
browser.fullscreen.animateUp
ui.submenuDelay

What's so hard to support about a few about:config settings like the following booleans?
browser.downloadpanel.animate
browser.bookmark.animate
browser.arrowpanel.animate
browser.findbar.animate
browser.customize.animate

It's literally toggling a few lines of CSS off and on.  Does lacking an animation change how Firefox is supported?  Firefox has a precedent of about:config settings to control all previous animations.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Respectfully, what does the UX roadmap have to do with marking this WONTFIX?  Is there something wrong with leaving a valid report open for when your roadmap changes?  Is the philosophy of UX that things should behave only one way and only configurable by third party hacks?
No time for configuration settings on the roadmap but plenty of time for bouncing unicorns.
(In reply to shiretoko212 from comment #23)
> Yes, I picked up the handle shiretoko as a tribute to 3.5 and have been
> using it since those former days.
> 
> The following settings exist to control animations within Firefox at the
> moment in about:config.
> browser.tabs.animate
> browser.panorama.animate_zoom
> general.smoothScroll
> browser.fullscreen.animateUp
> ui.submenuDelay
> 
> What's so hard to support about a few about:config settings like the
> following booleans?
> browser.downloadpanel.animate
> browser.bookmark.animate
> browser.arrowpanel.animate
> browser.findbar.animate
> browser.customize.animate
> 
> It's literally toggling a few lines of CSS off and on.  Does lacking an
> animation change how Firefox is supported?  Firefox has a precedent of
> about:config settings to control all previous animations.

I think the download panel has a pref already, same for customise.
(In reply to shiretoko212 from comment #23)
> What's so hard to support about a few about:config settings like the
> following booleans?
> browser.downloadpanel.animate
> browser.bookmark.animate
> browser.arrowpanel.animate
> browser.findbar.animate
> browser.customize.animate

They proportionally multiply the number of scenarios we have to care about.

> It's literally toggling a few lines of CSS off and on.

No, it isn't, because there's a bunch of JS code that expects these animations to be there. Some of the examples you have cited before cause real bugs when altered. So "just a few lines of CSS" is seriously misleading.

>  Does lacking an animation change how Firefox is supported?

Animations make a difference to users' perceptions of the browsers. Polish like this is important. Having individual toggles for all of them is a lot of work.

> Firefox has a precedent of about:config settings to control all previous animations.

And it's a bad precedent. We should be much more reluctant to add prefs for every single thing people might not necessarily be awestruck by the first time they see it.



In any case, this is a duplicate of the bug to actually introduce the preference for another reason, which is that this whole animation thing broke stuff for certain window managers on Linux, because Linux. :-\
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1001234
Looks like Firefox development has taken a steep turn downhill if that reply is representative of Mozilla.  Good thing the unpaid community will do your work for you in providing appropriate accessibility and performance features.  I'll leave this bug alone now.
(In reply to shiretoko212 from comment #28)
> Looks like Firefox development has taken a steep turn downhill if that reply
> is representative of Mozilla.  Good thing the unpaid community will do your
> work for you in providing appropriate accessibility and performance
> features.  I'll leave this bug alone now.

He's mostly right for all the concerns. But a more global and faster solution would be a pref to disable all actual browser animations.
How the times are changing...
> http://website-archive.mozilla.org/www.mozilla.org/firefox_vpat/firefox-vpat-3.html
> (h) When animation is displayed, the information shall be displayable in at least
> one non-animated presentation mode at the option of the user.

> Supports:
> An option to provide to display animation in a non-animated presentation mode
> is provided. 

(In reply to shiretoko212 from comment #28)
> Good thing the unpaid community will do your
> work for you in providing appropriate accessibility and performance
> features.

Sad to see that after the Eich-situation, Moz-devs are now embracing ableism too.
(In reply to Elbart from comment #30)
> How the times are changing...
> > http://website-archive.mozilla.org/www.mozilla.org/firefox_vpat/firefox-vpat-3.html
> > (h) When animation is displayed, the information shall be displayable in at least
> > one non-animated presentation mode at the option of the user.
> 
> > Supports:
> > An option to provide to display animation in a non-animated presentation mode
> > is provided. 
> 
> (In reply to shiretoko212 from comment #28)
> > Good thing the unpaid community will do your
> > work for you in providing appropriate accessibility and performance
> > features.
> 
> Sad to see that after the Eich-situation, Moz-devs are now embracing ableism
> too.

As I noted earlier, adding a pref is being tracked in a different bug, which is why I marked this as a duplicate. Firefox has always been at the forefront of accessibility support. I am actually deeply offended by your suggestion to the contrary, considering I myself once did some accessibility work under a grant from the Mozilla Foundation when WAI-ARIA was still relatively new, and have also done accessibility assessment for a consultancy group. I strongly reject any claim of being discriminatory in my previous comment, or "embracing ableism", or anything of the sort. I was simply replying to the assertion that "it's easy" and that we should have individual prefs for every single animation (which is a much bigger maintenance burden than having a single one).
Spoke to Gijs on IRC, I think this is not a dupe of bug 1001234 (that won't necessarily add a pref, and is a temporary measure).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to Matthew Turnbull [Bluefang] from comment #33)
> https://addons.mozilla.org/firefox/addon/kill-panel-animations/
> https://github.com/SparkyBluefang/KPA/blob/master/chrome/content/overlay.xml
> 
> It's simple enough to do this. I don't know what the fuss is about.

Would you like to submit a patch ? You can watch tutorials at codefirefox.com .
Thanks for the info, I hate animations, makes the UI feel slow (my of my pet hates with Chrome is the animations).
See Also: → 1004870, 456620
I have to disable this animation for reasons beyond personal preference, so I've been doing this:

panel[type="arrow"] {
    transition: none !important;
}

In Firefox 30, this causes the toolbar button for downloads to stick in the selected state after first selected (and the doorhanger is dismissed).  Before FF30 the button restores fine.  With "browser.download.debug" set to true, you can see that the recently redone downloads backend is not aware of the dismissed doorhanger.  I can file a new bug, but thought I'd post here in case this symptom is related to your effort.
(In reply to :Gijs Kruitbosch from comment #27)
> No, it isn't, because there's a bunch of JS code that expects these
> animations to be there. Some of the examples you have cited before cause
> real bugs when altered. So "just a few lines of CSS" is seriously misleading.

Wait. What? Animations are supposed to eventually be async. Why is anything waiting on them? Changing the CSS is already a maintenance burden, as that's a lot of what themes do. Why can't the JS deal with failed animations?

I'm using that addon above because the new panel animations are really, really jarring visually. Nothing seems to be breaking. 

(And, yes, I really wish I could keep the other animations. It's only the new PanelUI animations that suck.)
> Wait. What? Animations are supposed to eventually be async. Why is anything
> waiting on them? Changing the CSS is already a maintenance burden, as that's
> a lot of what themes do. Why can't the JS deal with failed animations?

That comment you responded to shouldn't apply any more to the panel animations, nor should the issue in comment 36, as the issues there have been fixed.

Until or if there is general way to disable all or specific animations, the only way to disable the PanelUI animation is by adding to userChrome.css:

#PanelUI-popup[type="arrow"] { transition-property: none; }
Also see bug 1004870. Windows already has options to disable menu animations but Firefox ignores them. Firefox should behave like other applications in the same OS.
Duplicate of this bug: 1096409
This is an accessibility issue for people with neurological problems. Especially when the animation is choppy (which is ALWAYS when a page is loading, something else is happening, og just randomly).

Accessibility aside, defending animations because browsers are judged by polish is bizarre when the animations are so choppy. The bookmarks menu animation has to be the least polished part of Firefox (assuming you want an animation). I have an Intel 4570S 4-core desktop processor doing no background tasks, the choppyness is present on Windows 10 and Linux.

The most visually annoying behaviour is when the closing animation starts fading the menu out, then the menu DISAPPEARS, then shows, then disappears for good. Effectively a "blinking" effect. Luckily it's rare. Even rarer for me, as I mostly use SeaMonkey, which doesn't have this problem. ;)

Sometimes the menu closes without a fade effect (or blinking). It just closes normally. I do not have any explanation for this.

Clicking rapidly on the bookmarks menu button (such as closing the bookmarks, then opening them again) occasionally brings up weird animation behaviour, such as the menu _fading_ in WITHOUT the slide/zoom effect.

If a lot of JavaScript depends on an animation then that is a programming flaw. If it's not a lot of code, then it's not a good excuse.

Opinion: An individual preference for every animation is not needed.
Extra information: Animations in the tab bar (sliding tabs) are also choppy.
And it's not just that an individual preference isn't needed, I think it's unwanted. It's better to turn off all animations with one preference.
Duplicate of this bug: 1330344
See Also: → 1352069
You need to log in before you can comment on or make changes to this bug.