Bug 141023

Summary: WebKit incorrectly treats unitless "0" in -webkit-animation value as "animation-delay", instead of "animation-iteration-count"
Product: WebKit Reporter: Daniel Holbert <dholbert>
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: ahmad.saleem792, dino
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=203484
Attachments:
Description Flags
testcase 1 none

Description Daniel Holbert 2015-01-28 19:17:14 PST
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.)
Comment 1 Ahmad Saleem 2022-10-01 18:12:56 PDT
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!