Created attachment 263471 [details] Reduced test case DESCRIPTION In recent versions of WebKit, if an instantaneous CSS animation is defined with animation-fill-mode = forwards and a positive value for animation-delay, the end result is that the values specified for the 0% keyframe are applied to the animated element outside of the animation, instead of one for the 100% keyframe. I believe this is wrong, as per the CSS spec for animation-duration (http://www.w3.org/TR/css3-animations/#animation-duration-property): "When the duration is ‘0s’ ‘animation-fill-mode’ still applies, so an animation that fills backwards will show the value of the 0% keyframe during any delay period, and an animation that fills forwards will retain the value specified at the 100% keyframe, even if the animation was instantaneous." I initially found this in WebKitGTK 2.10.1, but then I've tried in my Mac Mini with OS X Yosemite and I could reproduce it in the latest WebKit nightly, so it looks like a cross platform bug. More specifically, in OS X: * Works OK with Safari 9.0 (10601.1.56.2) * FAILS with WebKit Nightly r191175 I'm attaching a test case I wrote, so that the bug can be easily reproduceable. STEPS TO REPRODUCE 1. Uncompress the contents of the attached file and load index.html in MiniBrowser / Safari + WebKit Nightly 2. You should see some text and 4 red circles at the beginning with the background going darker for 2 seconds EXPECTED OUTOME After the background has gone darker for 2 seconds the delayed zero-seconds animation to change opacity of the first red circle from 0% to 100% should be instantaneously applied, leaving that first circle visible afterwards (together with the other 3 circles, which have slightly different animation parameters) ACTUAL OUTCOME The first circle disappears, while the other three remain visible due to either: * Not using a delay * Using animation-fill-mode = none * Using a non-zero value for animation-duration
Created attachment 263473 [details] Reduced test case (text only) Hmm... I just realized that I don't need any image for this test case, even though that's how I initially found the problem, aspplying the animation over normal text will cause the same problem. Thus, attaching now an updated version of the test case I've just tested.
<rdar://problem/23174908>
I don't get the last test case. The page background is animating, but the content suggests the text items should appear/disapper?
(In reply to comment #3) > I don't get the last test case. The page background is animating, but the > content suggests the text items should appear/disapper? Sorry for the confusion: the page background animation is simply a cosmetic thing to help see the problem better by running the test manually, but it's not really relevant to the problem at hand. The important problem here is that the text will disappear even if opacity at the 100% keyframe is set to 1 and fill-mode is set to forwards, which apparently happens because the duration of the animation is zero (and so I'm guessing it's taking the value of the 0% keyframe instead). I only added the background thing so that it was easier to see it, but perhaps was a mistake because it was not strictly needed for the issue at hand. In any case, I just found that the patch for WebKit bug 146996 ("Safari mis-applies "animation-fill-mode: forwards" when using fractional iteration count") is the one who broke this behaviour: http://trac.webkit.org/changeset/187121 I've double checked it myself and I can confirm that reverting that patch gets the test case running fine once again. Simon, any idea?
(In reply to comment #4) > The important problem here is that the text will disappear even if opacity > at the 100% keyframe is set to 1 and fill-mode is set to forwards, which > apparently happens because the duration of the animation is zero (and so I'm > guessing it's taking the value of the 0% keyframe instead). Ah! Note that there seems to be also a link between this problem and animation-delay, since setting that property to 0s gets the animation working fine too. Also, setting fill-mode to 'none' gets the expected result as well, as you can see in the attached test case. Any input on this issue would be highly appreciated, thanks in advance!
This bug happens because of the zero-duration animation. We end up interpolating by mistake between the last and first keyframe, and choosing the first keyframe's values.
Created attachment 263984 [details] Patch
Comment on attachment 263984 [details] Patch Clearing flags on attachment: 263984 Committed r191540: <http://trac.webkit.org/changeset/191540>
All reviewed patches have been landed. Closing bug.
Thanks for the patch, Simon. For the record, I can confirm it fixed the original issue I reported it for, and that your test case fails without the patch and passes with it.