Unable to repro this issue on Windows 10 for Google Chrome Canary Version - 54.0.2826.0

Screen-recording is attached.

@cyril.auburtin: Could you please perform the steps mentioned beneath and let us know your observations.

1. Update your Google Chrome Canary Version - 54.0.2826.0
2. Re-test the same on a clean profile [chrome://settings -> Add Person - Do not login]

Thank you.

Deleted: 637159.mp4 2.6 MB

	637159.mp4 2.6 MB View Download

Excuse me rnimmagadda, like most often, I'm not good at describing the issue:

Testing on Version 54.0.2826.0 canary (64-bit): https://jsfiddle.net/9ot7w02g/13/

on the gif, when I press play, in console I see 'before' and an emoji, the one that was selected on screen so it's fine.

On finish, I see in console the next emoji, this one correspond to the current style that I tried to apply, but you notice that at the end of animation, it's still the same emoji than an start. Actually it's impossible to change the transform property of this element from devtools, it's not reflected visually at all.

Finally when starting another animation, the changes get applied, magically, it's unfreezed when loading a new animation

Deleted: animatebug.gif 414 KB

	animatebug.gif 414 KB View Download

It's due to fill:'forwards' as explained here https://bugzilla.mozilla.org/show_bug.cgi?id=1294601

====================================

Good Build:

51.0.2662.0    Base Position: 378134


Bad Build:

51.0.2675.0    Base Position: 380818

=====================================

Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 52.0.2743.116

This is a regression issue broken in M52, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/89de433c4e57f4de24e6fff63b852af02cf0b58a..209701e1c7ecd85853d576b62ef98aab3047e31e

Suspecting Commit: c0846df098b6a1ba6487d7c351d1f3bb0d6f7690

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

@suzyh: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Sure, I'll take a look.

The example uses a new syntax that was introduced in the patch referenced in #4. To test behaviour prior to that,

"""
{transform:[foo.style.transform, `translateY(${y-480}px)`]},
"""

should be replaced with

"""
[{transform:foo.style.transform}, {transform:`translateY(${y-480}px)`}],
"""

See https://jsfiddle.net/9ot7w02g/14/


Proceeding on the assumption that it is not a regression....

It's not clear to me what exactly the bug is here. Adding logging statements before and after "foo.style.transform = ..." in the onfinish handler shows that the value is modified, although it is not repainted.

Since there is a fill:'forwards', it's not clear to me which value of foo.style.transform is expected to 'win out': the one from the fill, or the one from the onfinish handler.

I'll get a second opinion, but to move forward I think we'll need a simpler test case that has a clear expected behaviour.

Yes, I was using this new syntax, and testing on Canary.

By the way, again removing fill: 'forwards' from the options makes it work like I wanted, I guess this options kind of 'freeze' the animated property just after. Thanks for you inputs