Developers think it's cool. 
The old UI is almost completely removed from the source code.

I've switched to another chromium fork because Material Design looks and feels out of place in a desktop PC application. Most irritatingly, there's no way to disable the ugly animations like MD "ripple" (or whatever) on click, possibly the worst animation choice for a non-game desktop app I saw since the '90s.

We won't be providing a switch to disable Material Design, but we would like to be accommodating of accessibility needs.

Do you have "animate controls and elements inside windows" disabled in your Windows system settings?  If so, then perhaps the bug here is that we don't respect that system setting and disable our own animations in response.

Or is there another way that you normally set your system to minimize this problem?

I support having a way to disable animations for accessibility purposes. It's not clear to me if the Windows system settings are meant to govern application behavior, but currently they do not seem to change Chrome (Win10/Chrome 54).

Yes, apps on the system should respect these.

We should control things like the MD ripple by Animation::ShouldRenderRichAnimation(), which reads the appropriate system setting on Windows.  I might also change this function's name and comments; it implies it should only apply to "big" animations like the start download effect, but https://msdn.microsoft.com/en-us/library/windows/desktop/dd318018(v=vs.85).aspx notes that it's much more broad and basically should cover all animations in the client area.

The easiest way to implement that would be to make Animation itself just snap to the final state whenever this is on, but that might cause some surprising bugs.  Auditing all animations for this is going to be an annoying job and prone to people doing the wrong thing later, though.  Maybe there's a way we can default Animation to running instantly when this is on and let specific people opt out as needed.

This would be a good task for several weeks of an L4's time.

I can confirm that this behavior does NOT respect setting "animate controls and elements inside windows" 
I have it turned OFF (Windows 7, 64) but this animation is still playing
This one really is an accessibility monster

I agree with comment's #3 sentiment on ripple effect
It plays AFTER action, so it will surely distract anyone, not only autistic people.
It copies that of mobile touchscreens - but those have so many usability issues making quick efficient work on them impossible, that no one cares if you add another one. On desktop this is a major annoyance

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03ac98e06185f954738f1d3ec98c387b412c53f3

commit 03ac98e06185f954738f1d3ec98c387b412c53f3
Author: bruthig <bruthig@chromium.org>
Date: Thu Nov 24 04:47:12 2016

Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation().

Forces an animation duration of 0 for all ink drop animations if
ShouldRenderRichAnimations() returns false.

BUG= 658384 

Review-Url: https://codereview.chromium.org/2520353004
Cr-Commit-Position: refs/heads/master@{#434301}

[modify] https://crrev.com/03ac98e06185f954738f1d3ec98c387b412c53f3/ui/views/animation/flood_fill_ink_drop_ripple.cc
[modify] https://crrev.com/03ac98e06185f954738f1d3ec98c387b412c53f3/ui/views/animation/ink_drop_highlight.cc
[modify] https://crrev.com/03ac98e06185f954738f1d3ec98c387b412c53f3/ui/views/animation/square_ink_drop_ripple.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7

commit 146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7
Author: Ben Ruthig <bruthig@chromium.org>
Date: Tue Nov 29 15:06:00 2016

Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation().

Forces an animation duration of 0 for all ink drop animations if
ShouldRenderRichAnimations() returns false.

BUG= 658384 

Review-Url: https://codereview.chromium.org/2520353004
Cr-Commit-Position: refs/heads/master@{#434301}
(cherry picked from commit 03ac98e06185f954738f1d3ec98c387b412c53f3)

Review URL: https://codereview.chromium.org/2535243002 .

Cr-Commit-Position: refs/branch-heads/2924@{#153}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7/ui/views/animation/flood_fill_ink_drop_ripple.cc
[modify] https://crrev.com/146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7/ui/views/animation/ink_drop_highlight.cc
[modify] https://crrev.com/146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7/ui/views/animation/square_ink_drop_ripple.cc

Removing merge-merged-2924 as I've updated issue 668519 to track that work.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/096c61e0ff96f537964e740e55eb3ae518977a55

commit 096c61e0ff96f537964e740e55eb3ae518977a55
Author: bruthig <bruthig@chromium.org>
Date: Tue Nov 29 23:11:32 2016

Revert of Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation(). (patchset #1 id:1 of https://codereview.chromium.org/2535243002/ )

Reason for revert:
Failing tests on windows bots.  I suspect the tests are actually dependent on environment settings which is not good and will require time to investigate.

Original issue's description:
> Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation().
>
> Forces an animation duration of 0 for all ink drop animations if
> ShouldRenderRichAnimations() returns false.
>
> BUG= 658384 
>
> Review-Url: https://codereview.chromium.org/2520353004
> Cr-Commit-Position: refs/heads/master@{#434301}
> (cherry picked from commit 03ac98e06185f954738f1d3ec98c387b412c53f3)
>
> Committed: https://chromium.googlesource.com/chromium/src/+/146e4c96e3e45a0edb5d04f6b76d44e86cdb24f7

TBR=
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 658384 

Review-Url: https://codereview.chromium.org/2543443002
Cr-Commit-Position: refs/branch-heads/2924@{#171}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/096c61e0ff96f537964e740e55eb3ae518977a55/ui/views/animation/flood_fill_ink_drop_ripple.cc
[modify] https://crrev.com/096c61e0ff96f537964e740e55eb3ae518977a55/ui/views/animation/ink_drop_highlight.cc
[modify] https://crrev.com/096c61e0ff96f537964e740e55eb3ae518977a55/ui/views/animation/square_ink_drop_ripple.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc642e808f2aa44bc748c5a528c16cd78c054030

commit cc642e808f2aa44bc748c5a528c16cd78c054030
Author: bruthig <bruthig@chromium.org>
Date: Wed Nov 30 16:12:51 2016

Revert of Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation(). (patchset #4 id:60001 of https://codereview.chromium.org/2520353004/ )

Reason for revert:
Failing tests on windows bots.  I suspect the tests are actually dependent on environment settings which is not good and will require time to investigate.

Original issue's description:
> Disabled ink drop animations based on gfx::Animation::ShouldRenderRichAnimation().
>
> Forces an animation duration of 0 for all ink drop animations if
> ShouldRenderRichAnimations() returns false.
>
> BUG= 658384 
>
> Committed: https://crrev.com/03ac98e06185f954738f1d3ec98c387b412c53f3
> Cr-Commit-Position: refs/heads/master@{#434301}

TBR=pkasting@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 658384 

Review-Url: https://codereview.chromium.org/2539913004
Cr-Commit-Position: refs/heads/master@{#435276}

[modify] https://crrev.com/cc642e808f2aa44bc748c5a528c16cd78c054030/ui/views/animation/flood_fill_ink_drop_ripple.cc
[modify] https://crrev.com/cc642e808f2aa44bc748c5a528c16cd78c054030/ui/views/animation/ink_drop_highlight.cc
[modify] https://crrev.com/cc642e808f2aa44bc748c5a528c16cd78c054030/ui/views/animation/square_ink_drop_ripple.cc

Could you please provide the TEST steps to verify the fix manually.

Sorry, this doesn't require any verification.  This issue got the wrong merge labels because https://codereview.chromium.org/2520353004/ referenced the wrong issue number. 

Thanks for the update in #18.

The current animation looks ugly and distracting on my fast PC with 8-core 4GHz CPU and nVidia 750 Ti GPU I even see the stages of the animation, one of which has a black background (not observable on a slower PC, arguably), so I have to use a chromium fork that doesn't show the animation. Please re-apply the reverted fix.

Oops, the comment above was about chrome extensions popup animation, not inkdrop.

Could an animation setting be created for Chrome OS?

I hope an option can be implemented to disable the animations.

The animations are extremely bothersome and distracting.
 

This has been going on for years - started with Google Earth. Google is obsessed with this distracting animations. Is it another Apple thing they want so desperately?

Ben, you took a shot at this in November but didn't have time to look into the test failures and so reverted.

Can you (a) reland this even if it requires disabling tests for now (fixing the bug is better than having working tests) and (b) look into the test issue?  This is sitting on the floor and while it does affect a smaller group of users, there's a11y impact here and we do need to fix.

(Although I guess re-enabling the part you disabled would be more properly under bug 668519 than here, which I didn't realize -- but I'd also like to see forward progress on this larger bug.)

Assigning to lpalmaro@ to determine if/what other animations should respect the gfx::Animation::ShouldRenderRichAnimation() flag.

lpalmaro is ooo. 

#30 could you expand on the question so that I can answer? The idea here is to disable all Chrome's-chrome animations, across top chrome, secondary UI, and (if possible) chrome:// content pages when the OS setting to disable them is set.

What are the other animations beyond the ink drop, that are not currently disabled based on the accessibility switch but should be?  It would be nice to have these broken out into blocking issues, or captured in a doc, so that eng knows what exactly they are and can cherry-pick the ones they are able to tackle.

I imagine the list of animations (or subsystems) is large and diverse enough that it doesn't make sense to park the work on one owner/team.  Even if we do as Comment 7 suggests and snap all animations to their targets; there are multiple different animations systems that would need to implement this (e.g. gfx::Animation, ui::LayerAnimator, and whatever system backs chrome:// pages).

I don't think that list of animations exists, but the MD top chrome changes were what caused the regression as far as the users in this bug are concerned.

+helene, do you happen to have a list of places in desktop where we use animation/motion? We're trying to respect an accessbility setting in Windows that disables animations but per #32 the code isn't structured in a way that makes it easy to discover them.

+hwi, if we can't turn up the rest of the cases now, perhaps this work could be folded into the desktop accessibility auditing effort.

Yes, here's an audit of animation transitions on Win10
https://docs.google.com/presentation/d/1OgN7kGbd1qVEjgzooIS-TZcI_AOXACQRbaB2Sn53c7k/edit#slide=id.g19046819d4_0_76

Circling back here, I agree that after reading the comments in this bug, it seems the MD animations are higher priority to be able to disable. It will be helpful to do a broader analysis of other animations across Chrome that we would want to add to the bucket of motions a user could disable (Hwi, hopefully you and I can work on that together as part of our broader efforts). But for now, I think we need to figure out who could work on this and pick up where Ben had left off. Any ideas? Ben, would you be able to take another look? 

There is already a slow animations flag on Chrome OS. chrome://flags/#ui-slow-animations

Ben, friendly ping 

Sorry, this fell off my radar due to leaving the Chrome team.  Which means, unfortunately, that I am not able to pursue this.  If you do find someone to take on this work I can possibly be helpful as a consultant though.

To make this bug easier to search for, the system setting on macOS is called "reduce motion". When turned on, the OS tends to use cross fades in place of other animations.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This seems to be quite duplicate with issue 8944. WDYT?

They're close enough that we can let that bug cover this.  I'd dupe the other way, but you're already doing work there.