I'll take a first look.

It looks like the animation does occur, but you have to leave it scrolled at the top for a little while. The header animation appears to be controlled from a timer that gets set from onScroll. It looks like the issue is that we're deferring that timer from firing as part of our "expensive task deferral" ( issue 574343 ) but that should have launched in M53 so I'm not sure what the difference is. Should also note, the repro is not consistent, I had to restart Chrome and navigate to the page a few times.

Sami/Alex, are you aware of any changes to scheduling that may have changed here recently? I suppose another possibility might be that something else got more expensive which is causing the timer to get flagged as long running.

For a more consistent repro, continually fling down while the page is loading looks like it causes the time to be flagged.

I'll confirm later, but it might be related to one of Sami's interventions.

+altimin@ as FYI

I tried this on a nexus 7v2, I didn't notice the animation getting blocked although it was animating at low FPS (perhaps 20fps) and looked a bit bad.

If the scheduler is expecting a touch start soon, then it will block loading and timer tasks if deemed expensive.  Specifically if the 99% run time is >50 ms.

In this case on the 7v2 the expected_timer_task_duration was 10.254ms so it wasn't getting blocked however expected_loading_task_duration was 70.6184ms so they where.

If at all possible code should really be using rAF for JS controlled animation.

So this is a P1; we really should have an owner. alexclarke@ are you indicating this isn't a scheduling issue by un-assigning yourself?

I chatted to Sami and we think this is working as intended.  We've been telling web devs for years to use rAF for animations. 

Looking at the source code I can see it's trying to update the animation at 10hz.  They can do this with rAF by ticking the animation every 6th frame.

I've filed an internal bug: https://b.corp.google.com/issues/32367396