984589 - Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on

Status: RESOLVED FIXED

(Firefox :: Menus, defect, P3)

Description

[u501112]

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

[:Gijs (he/him)]

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.

Comment 3

[u501112]

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

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 5

[u501112]

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

[Mike Conley (:mconley) (:⚙️)]

Try:

.panel-arrowcontainer {
  opacity: 1;
  transform: none;
}

Comment 7

[u501112]

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

[Tim Nguyen :ntim]

(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;
}

Comment 9

[u501112]

Thanks, Tim.  Works now.  I submitted it to userstyles.org via http://userstyles.org/styles/99666/disable-arrow-panel-animations

Comment 10

[u501112]

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

[Tim Nguyen :ntim]

(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

[Tim Nguyen :ntim]

(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;}

Comment 13

[u501112]

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

[Tim Nguyen :ntim]

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

Comment 15

[Tim Nguyen :ntim]

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.

Comment 16

[u501112]

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

[Tim Nguyen :ntim]

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

Comment 18

[u501112]

I already tried transition: none !important; as well. It doesn't disable the new animation.  Any other ideas?

Comment 19

[Tim Nguyen :ntim]

transform:none !important;

Comment 20

[u501112]

That doesn't work either.

Comment 21

[u501112]

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

[Jennifer Morrow [:Boriss] (UX)]

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

Comment 23

[u501112]

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.

Comment 24

[u501112]

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?

Comment 25

[u501112]

No time for configuration settings on the roadmap but plenty of time for bouncing unicorns.

Comment 26

[Tim Nguyen :ntim]

(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

[:Gijs (he/him)]

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

Comment 28

[u501112]

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

[Tim Nguyen :ntim]

(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

[Elbart]

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

[:Gijs (he/him)]

(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

[:Gavin Sharp [email: [e-mail]]]

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

[Matthew Turnbull [Bluefang]]

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

[Tim Nguyen :ntim]

(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

[Hugh]

Thanks for the info, I hate animations, makes the UI feel slow (my of my pet hates with Chrome is the animations).

Comment 36

[Adam Moore]

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

[Terrell Kelley]

(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

[Neil Deakin]

> 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

[vtqobex]

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

[trondsg+bugzilla+mozilla]

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

[trondsg+bugzilla+mozilla]

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

[mmortal03]

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

[MarjaE]

I don't think they use xul any more. Try commenting out the namespace line and see if that helps.

Comment 46

[mmortal03]

(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

[mmortal03]

Found a solution. It looks like it's as easy as setting xul.panel-animations.enabled to false.

Comment 48

[trondsg+bugzilla+mozilla]

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.

Comment 49

[:Gijs (he/him)]

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.

Comment 50

[Amy Churchwell [:amy]]

Attachment: Bug 984589 - Sideways sliding animation in panels should be disabled when prefers-reduced-motion is turned on. r?sfoster,mhowell

Comment 51

[MarjaE]

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

[Pulsebot]

Pushed by [e-mail]:
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

[Cristian Tuns]

Backed out for causing multiple failures

• Backout link

• Push with failures

• Failure Log

• Failure line: TEST-UNEXPECTED-FAIL | browser/components/enterprisepolicies/tests/browser/browser_policy_support_menu.js | Test timed out -

• Failure Log 2

• Failure line: TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_addCertException.js | Test timed out -

• Failure Log 3

• Failure line:TEST-UNEXPECTED-FAIL | devtools/server/tests/chrome/test_styles-applied.html | Should have the expected number of rules. - got 10, expected 9

Comment 54

[Amy Churchwell [:amy]]

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

[Molly Howell (she/her) [:mhowell]]

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

Comment 56

[Pulsebot]

Pushed by [e-mail]:
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

[Marian-Vasile Laza]

Backed out changeset a55825557cf0 (Bug 984589) for bc failures on browser_identityPopup_focus.js.
Backout link
Push with failures <--> bc2
Failure Log

Comment 58

[Pulsebot]

Pushed by [e-mail]:
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

Comment 59

[Serban Stanca]

https://hg.mozilla.org/mozilla-central/rev/6f3920ecd695