Bug 141023 – WebKit incorrectly treats unitless "0" in -webkit-animation value as "animation-delay", instead of "animation-iteration-count"

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Animations

[Daniel Holbert]

Created attachment 245599 [details]
testcase 1

STR:
 1. Load attached testcase.

EXPECTED RESULTS:
 Lime background on div.

ACTUAL RESULTS:
 Red background on div.


Firefox 35 gives me EXPECTED RESULTS.
These webkit-based browsers on Ubuntu 14.10 give me ACTUAL RESULTS:
 - epiphany-browser 3.10.3, using libwebkit2gtk-3.0-25
 - Midori 0.4.3, not sure what webkit version

DISCUSSION:
The testcase has:
  -webkit-animation: fadeIn 1s ease both 0;
  animation:         fadeIn 1s ease both 0;

It seems that webkit is parsing the final "0" there as a valid <time> and hence using it as an "animation-delay" value. However, it's not a valid <time> -- CSS <time> values require units. So it should instead be interpreted as an "animation-iteration-count" value, and be interpreted to mean that the animation shouldn't play (or should freeze at its first frame).

See https://code.google.com/p/chromium/issues/detail?id=453182 for corresponding blink bug, with more discussion of the spec & how <time> requires units. (particularly comments number 6 and 7 there.)

[Ahmad Saleem]

I am not able to reproduce this bug in Safari 16 and this shows "lime" color background, which is expected. I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Thanks!