New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 608329 link

Starred by 2 users
Status: WontFix
Owner:
alancutter@chromium.org
Closed: May 2016
Cc:
█ ashej...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

Paused animation is unexpectedly started when the timing function is step-start.

Reported by j4ja...@gmail.com, May 2 2016 
Chrome Version       : 52.0.2716.0 (Official Build) dev-m (64-bit)
URLs (if applicable) : https://jsfiddle.net/83888h9u/
Other browsers tested:
    Firefox: OK (45.0.2)
         IE: OK (11.212.10586.0)
    MS Edge: OK (EdgeHTML 13.10586)

All browsers were tested on Windows 10 Pro (Version 1511 Build 10586.218).

What steps will reproduce the problem?
(1) Create an animation with the animation-play-state set to paused.
(2) Set the animation-timing-function to step-start.
(3) Create a 'to' keyframe which alters some property value (e.g. setting the text color).

What is the expected result?
The 'to' keyframe shouldn't take effect, since the animation isn't running (in the given example, the color should remain blue). 

What happens instead?
The 'to' keyframe does take effect, and the property is changed (in the given example, the color changes to red).

Example html:
<div class="blue-red">This should be blue.</div>
<style>
  .blue-red {
    color:blue;
    animation-name:color-red;
    animation-play-state:paused;
    animation-duration:1s;
    animation-timing-function:step-start;
  }
  @keyframes color-red {
    to { color:red; }
  }
</style>
Paused animation.png
108 KB View Download

Comment 1 by ashej...@chromium.org, May 3 2016

Cc: ashej...@chromium.org
Components: Blink>Animation
Labels: -Type-Bug -Pri-3 hasbisect M-52 OS-All Pri-1 Type-Bug-Regression
Owner: alancutter@chromium.org
Status: Assigned (was: Unconfirmed)
The above issue is reproducible on All-OS (Windows (10 & 7), Mac 10.11.4 & Ubuntu 14.04) with chrome versions : 50.0.2661.94(Stable), 51.0.2704.29(Beta), 52.0.2716.0(Dev) & 52.0.2723.0(Canary).

This is a regression issue broken in M43 chrome version.

Manual bisect info
==================
Last known Good build: 43.0.2336.0
First known Bad build: 43.0.2337.0

Narrow bisect
=============
You are probably looking for a change made after 321092 (known good), but no later than 321099 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/ee11c06cea48829c79878a51b2afb875c943d48b..71e08c4d22fb6035bf80b8a110ede3e3d840861b

From the narrow bisect, plausible offending CL: https://codereview.chromium.org/1004623010 ?

@alancutter: Hey, can you please check the above issue and see if it's related to your change ?

Feel free to route the above issue to concern dev, if it's not related.

I really appreciate your help.

Thank you!

Comment 2 by alancutter@chromium.org, May 3 2016

Labels: -Type-Bug-Regression Type-Bug
Status: WontFix (was: Assigned)
The change https://codereview.chromium.org/1004623010 just enables unprefixed CSS animation properties, prior to that change they were ignored and no animation was started. This is a non regression issue.

The animation is in this example is paused yet active. The step-start timing function gives you 100% at 0% progress which is why you see the end frame for the beginning of the animation.
https://www.w3.org/TR/css3-transitions/#transition-timing-function-property
Other browsers are assuming that all timing functions are 0% at 0% progress which is not the case for step(x, start) timing functions.

Alternate test case: https://jsfiddle.net/fj5buqs7/
Chrome and Firefox Nightly passes this test.

Comment 3 by ashej...@chromium.org, May 3 2016 

@alancutter: Thanks for the quick turnaround.

Thank you!
►

Sign in to add a comment