Tested the issue on chrome reported version 63.0.3239.84 using Mac 10.12.6 with steps mentioned below
1) Launched chrome reported version and launched the attachement given in comment#0
2) Clicked on "Add 1s to animation duration" button
3) Seen that jump of the orange box after clicking the button and movement of the orange box slows down

@Reporter:
Can you please find the attached screencast for your reference, could you please provide the screencst of excepted behaviour of the issue which helps us further triaging it from TE end in a better way.

Thanks!

Deleted: 798732.mp4 893 KB

	798732.mp4 893 KB View Download

I am unable to produce a screencast showing the expected behaviour but I can describe it more fully:

As the animation-duration value is being changed, I would expect the item to NOT jump but instead the speed it is moving to change. E.g. if the duration gets longer the speed should slow. If the duration decreases the item speed should increase.

It makes sense to me that when an animation-duration is changed it is the speed that should be 're-mapped' and not the position of the items.

Does that make sense?

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

Able to reroduce the issue on reported chrome version 63.0.3239.84 and latest chrome version 65.0.3311.3 using Mac 10.12.6, Windows-10 and Ubuntu 14.04. As the issue is seen from M50(50.0.2661.0) considering it as non-regression.

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

Per css-animations spec [1] "Changes to the values of animation properties while the animation is running apply as if the animation had those values from when it began. For example, shortening the animation-delay may cause the animation to jump forwards or even finish immediately and dispatch an animationend event. Conversely, extending the animation-delay may cause an animation to re-start and dispatch an animationstart event."


My reading of the current wording is that it actually asks for "current time" to remain as is and instead allow the animation output to jump thus your observation. web-animation has some cases where it prefers to adjust the start time so that the output does not jump. But I don't believe that applies to changes to duration. 

So I think the jump behavior is per spec thought perhaps not optimal (smcgruer@ wdyt?). If this is so then a bug should be filed against the spec first and mark this as WONTFIX.

Also this is not related to custom property at all, changing the duration directly has the same effect. Update title to reflect this.


[1] https://drafts.csswg.org/css-animations/#animations

Also this is not an interop issue. Removing the label.

FF and Chrome behave the same. Safari seems to have a bug in re-evaluating custom properties but that is not a Chrome interop issues.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.