Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on
Categories
(Firefox :: Menus, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox112 | --- | verified |
People
(Reporter: u501112, Assigned: amy)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
(Keywords: access, Whiteboard: [fidefe-quality-foundation] )
Attachments
(1 file)
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.
Comment 2•10 years ago
|
||
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.
Comment 4•10 years ago
|
||
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.
Comment 6•10 years ago
|
||
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?
Comment 8•10 years ago
|
||
(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; }
Updated•10 years ago
|
Thanks, Tim. Works now. I submitted it to userstyles.org via http://userstyles.org/styles/99666/disable-arrow-panel-animations
Reporter | ||
Comment 10•10 years ago
|
||
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?
Comment 11•10 years ago
|
||
(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.
Comment 12•10 years ago
|
||
(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;}
Reporter | ||
Comment 13•10 years ago
|
||
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.
Comment 14•10 years ago
|
||
(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.
Updated•10 years ago
|
Comment 15•10 years ago
|
||
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.
Reporter | ||
Comment 16•10 years ago
|
||
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?
Comment 17•10 years ago
|
||
(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.
Reporter | ||
Comment 18•10 years ago
|
||
I already tried transition: none !important; as well. It doesn't disable the new animation. Any other ideas?
Comment 19•10 years ago
|
||
transform:none !important;
Reporter | ||
Comment 20•10 years ago
|
||
That doesn't work either.
Reporter | ||
Comment 21•10 years ago
|
||
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
Comment 22•10 years ago
|
||
(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.
Reporter | ||
Comment 23•10 years ago
|
||
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.
Reporter | ||
Comment 24•10 years ago
|
||
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?
Reporter | ||
Comment 25•10 years ago
|
||
No time for configuration settings on the roadmap but plenty of time for bouncing unicorns.
Comment 26•10 years ago
|
||
(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.
Comment 27•10 years ago
|
||
(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. :-\
Reporter | ||
Comment 28•10 years ago
|
||
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.
Comment 29•10 years ago
|
||
(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.
![]() |
||
Comment 30•10 years ago
|
||
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.
Comment 31•10 years ago
|
||
(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).
Comment 32•10 years ago
|
||
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).
Comment 33•10 years ago
|
||
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.
Comment 34•10 years ago
|
||
(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 .
Comment 35•10 years ago
|
||
Thanks for the info, I hate animations, makes the UI feel slow (my of my pet hates with Chrome is the animations).
Updated•10 years ago
|
Comment 36•9 years ago
|
||
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.
Comment 37•9 years ago
|
||
(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.)
Comment 38•9 years ago
|
||
> 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; }
Comment 39•9 years ago
|
||
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.
Comment 41•7 years ago
|
||
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.
Comment 42•7 years ago
|
||
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.
Comment 44•4 years ago
|
||
Should these userChrome.css modifications still work in 71.0? I've got:
toolkit.legacyUserProfileCustomizations.stylesheets = true
...but none of these modifications seem to work.
My userChrome.css is just as follows:
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
.panel-arrowcontainer {
opacity: 1;
transform: none;
pointer-events: all !important;
}
Comment 45•4 years ago
|
||
I don't think they use xul any more. Try commenting out the namespace line and see if that helps.
Comment 46•4 years ago
•
|
||
(In reply to MarjaE from comment #45)
I don't think they use xul any more. Try commenting out the namespace line and see if that helps.
I posted over in the Mozillazine forums, and it turns out that all the modifications I was trying were out of date (including the specific one above). You're right that the namespace line was unnecessary, but that wasn't the cause of the problem. It looks like the modifications in this bug report need changes, but I'm not knowledgeable enough about Firefox CSS code to make the changes. If I get something that works, I'll report back.
Comment 47•4 years ago
|
||
Found a solution. It looks like it's as easy as setting xul.panel-animations.enabled to false.
Comment 48•3 years ago
|
||
Thank you. This fixed the drop down animations.
However, the sideways animation in the main menu, when clicking a menu item that leads to a submenu, is still there.
Updated•2 years ago
|
Comment 49•2 years ago
|
||
The opening of the panels now obeys your OS's "reduce motion" preference, which can also be set in Firefox's about:config with ui.prefersReducedMotion
(numeric pref, set to 1 to prevent animations).
This doesn't appear to impact the sideways sliding of subview, so I've morphed the bug to cover that.
Updated•10 months ago
|
Updated•10 months ago
|
Updated•9 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Comment 50•8 months ago
|
||
Comment 51•8 months ago
|
||
The css in comment 38 no longer works. So for the only css I've found which blocks the animation is either:
/* De-Animate /
/ Note: this disables certain menus. */
@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
- { transition: none !important;
animation-duration: 0s !important; } - { transition:unset !important; }
or:
/* Remove some Random Annoying Animations in the Toolbar, from this author : annoying animations https://www.reddit.com/r/firefox/comments/37hw8o/how_to_disable_all_animations/ /
/ Note: this disables certain menus. */
- {
animation-delay: 0ms !important;
animation-duration: 0ms !important;
transition: none !important;
}
Both of which not only block the animation, but disable the menus.
Reducing Firefox's frame rate to 1/second still has the menus flash, although at least they don't smoothly animate. Ideally, the menus should work regardless of user css to block other, unrelated, animation.
Comment 52•8 months ago
|
||
Pushed by achurchwell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/77829bad66a9 Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on. r=sfoster,mhowell,desktop-theme-reviewers
Comment 53•8 months ago
|
||
Backed out for causing multiple failures
-
Failure line: TEST-UNEXPECTED-FAIL | browser/components/enterprisepolicies/tests/browser/browser_policy_support_menu.js | Test timed out -
-
Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_addCertException.js | Test timed out -
-
Failure line:TEST-UNEXPECTED-FAIL | devtools/server/tests/chrome/test_styles-applied.html | Should have the expected number of rules. - got 10, expected 9
Assignee | ||
Comment 54•8 months ago
|
||
Hi Molly, I think I am missing something -- I took a look at these test failures and it is not obvious to me how to adjust this patch to fix them, or why they are even failing?
Failure line:TEST-UNEXPECTED-FAIL | devtools/server/tests/chrome/test_styles-applied.html | Should have the expected number of rules. - got 10, expected 9
^ in particular is confusing me. Do you understand what is happening here, by chance?
Comment 55•8 months ago
|
||
(In reply to Amy Churchwell [:amy] from comment #54)
Hi Molly, I think I am missing something -- I took a look at these test failures and it is not obvious to me how to adjust this patch to fix them, or why they are even failing?
Failure line:TEST-UNEXPECTED-FAIL | devtools/server/tests/chrome/test_styles-applied.html | Should have the expected number of rules. - got 10, expected 9
^ in particular is confusing me. Do you understand what is happening here, by chance?
I looked up that test and immediately I see this comment:
// If our system stylesheets are prone to churn, this might be a fragile
// test. If you're here because of that I apologize, file a bug
// and we can find a different way to test.
So yeah, I think that's the situation we've hit here, adding a rule to xul.css must have caused this count to increase. Bumping the expected value to 10 does indeed make the test pass, and that might be the right short term solution, but I think it's worth pinging nchevobbe to discuss this before landing anything here.
The other two tests are both timing out waiting for ViewShown
events, even though the correct view is actually showing, which seems strange. So I looked up where that event is generated to see what might cause it to not be, and the only thing I could see that leads to that _activateView
function not being called would be this async call doing something unexpected. Which it is, right here; that transitionend
won't happen if there's no transition, so that immediately-awaited promise doesn't resolve. So the solution for these two tests I think would be to avoid setting the transform
property there in _transitionViews
at all when prefers-reduced-motion is set. Which, and this is a bit awkward, I think might make the entire current patch unnecessary? Although I guess that would also fix the devtools test, so there's that.
Assignee | ||
Updated•8 months ago
|
Comment 56•8 months ago
|
||
Pushed by achurchwell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a55825557cf0 Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on. r=sfoster,mhowell,desktop-theme-reviewers
Comment 57•8 months ago
|
||
Backed out changeset a55825557cf0 (Bug 984589) for bc failures on browser_identityPopup_focus.js.
Backout link
Push with failures <--> bc2
Failure Log
Comment 58•7 months ago
|
||
Pushed by achurchwell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f3920ecd695 Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on. r=sfoster,mhowell,desktop-theme-reviewers
Assignee | ||
Updated•7 months ago
|
Comment 59•7 months ago
|
||
bugherder |
Updated•7 months ago
|
Comment 60•6 months ago
|
||
I've reproduced the issue on Nightly 112.0a1 (2023-02-28) on Windows 10, macSO 13 and Ubuntu 22.04.
The issue is no longer reproducible on Nightly 113.0a1 (2023-04-02) on the same system.
I've checked following slide menus: Bookmarks, History, More tools and Help(from hamburger menu and customized toolbar).
I've tested using pref "ui.prefersReducedMotion" set to 1 and without the pref.
Also I've tested by disabling the Animations on my computer:
Windows 10
Show animations in Windows: off
or unchecking following options in Advanced System Settings
Animate controls and elements inside windows
- Animate windows when minimizing and maximizing*
Animations in the taskbar
macOS 13
Reduce Motion: on
Ubuntu 22.04
Enable Animations: off
Updated•4 months ago
|
Updated•4 months ago
|
Description
•