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

Daniel Holbert
Reported 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.)
Attachments
testcase 1 (398 bytes, text/html)
2015-01-28 19:17 PST, Daniel Holbert
no flags
Ahmad Saleem
Comment 1 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!
Note You need to log in before you can comment on or make changes to this bug.