Do you have a unit test or a CL that demonstrates this problem?

By animation, are you talking about ui-driven animation (i.e. cc::Layer::SetOpacity) or about cc/animation-driven animation?

It's ui::LayerAnimator, which is cc/animation I think?
I noticed that this happens when wallpaper has a foreround blur. Removing the blur also restores the animation.

Here is the CL to repro:
https://chromium-review.googlesource.com/c/chromium/src/+/1427453

Repro step:
1) Build chrome for chromeos on linux
2) Start it 
   $ out/Release/chrome --user-data-dir=/tmp/test --no-sandbox
3) Open desktop menu by right-clicking on desktop and select "Set Wallpaper".
4) Select wallpaper. Do not close the wallpaper picker window as it will cancel
  the wallpaper selection.
5) Press F5 to enter overview mode. With above CL, the background dimming
  does not fades in, but appleid abruptly.


Note:
a) Reverting the following change will restore animation
window_grid.cc:230       // AddChildView(label_container_);

b) Removing blur on wallpaper also restores the animation.
(see ifdef in window_selector_controller.cc:106)

Uploaded new patch with recent refactoring. Here are new file names:

window_grid.cc -> overview_grid.cc
window_selector_controller -> overview_controller.cc

I took a look at ui::LayerAnimator, but I am out of date on how most of our animation classes look.  Sending to flackr to triage/investigate.

Are CC animations supposed to work with render surfaces?

cc animations should not have to care about render surfaces, and render surfaces are just an implementation detail about implementing effects.  So, if an animation is not working because of a render surface, then that seems like a bug somewhere.