Looks like we stop playing the animation when the layout position (not accounting for the transform) leaves the frame.

+vmpstr is this potentially due to the work you did in  issue 254320 ?

This seems to be fixed on ToT (although I can repro on stable). Can someone verify?

Yes, it is fixed in Canary for me. It wasn’t when I opened this. I swear ;)

Correction, there seems to be still a constellation where the animation is stopped.

1.) Go here: https://googlechrome.github.io/ui-element-samples/custom-scrollbar/
2.) Scroll down

Blink>Animation covers CSS Animations/Transitions rather than animated GIFs.
Able to repro #4 on Linux Chrome 58. Cat stops animating after scrolling ~100px down.

This is fixed on the latest canary(59.0.3048.0) and the latest Beta(58.0.3029.33). Able to reproduce the issue on the latest stable(57.0.2987.110) with the jsbin from C#0. https://jsbin.com/zimumu/2/edit?html,css,output

Reverse bisected this to find the CL that fixed this.

Last bad build:   58.0.3029.5
First good build: 58.0.3029.6

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/1e2e898c6c8c2e603085654a6256dc581c74c67c..3a2c4663e5be244f263af1a7824bae449a927524

chrishtr@: If this is safe merge, shall we get this merged to M-57 as well.

Just to update the behavior regarding the https://googlechrome.github.io/ui-element-samples/custom-scrollbar/ from C#4. Tested on Windows-10 and below are the observations.

This is non regressed behavior:
===============================
50.0.2624.0: no cat
54.0.2786.0: no cat
55.0.2883.87: no cat
56.0.2884.0: no cat
56.0.2924.87: cat there but no animation 

Note that clicking the area where the cat would be progresses the animation 1 frame it seems.

My best guess is that this was fixed by this commit:

https://chromium.googlesource.com/chromium/src/+/3a2c4663e5be244f263af1a7824bae449a927524

Re C#10: The demo I link to in C#4 is still broken in today’s Canary (59.0.3054.0).

The bug is that we are applying scroll offset after perspective transform,
whereas we should be doing the reverse.

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

commit 2a2f87ba99ef135283c6cf81a173189e78357965
Author: chrishtr <chrishtr@chromium.org>
Date: Mon Apr 10 23:10:28 2017

Apply container offset and scroll between transform and containerperspective.

Previously, we mapped a visual rect from a child box to its container like this:

1. Apply layout offset from child to container.
2. Apply transform of child.
3. Apply perspective of container.
4. Apply scroll offset of container.
5. Apply clip of container.

This is incorrect. It should do steps 1 and 4 after step 2 and before step 3.

GeometryMapper already did this correctly. (And VisualRectMappingTest verifies
this).

BUG= 699140 

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

[modify] https://crrev.com/2a2f87ba99ef135283c6cf81a173189e78357965/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/2a2f87ba99ef135283c6cf81a173189e78357965/third_party/WebKit/Source/core/layout/LayoutBox.h
[modify] https://crrev.com/2a2f87ba99ef135283c6cf81a173189e78357965/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/2a2f87ba99ef135283c6cf81a173189e78357965/third_party/WebKit/Source/core/layout/VisualRectMappingTest.cpp