Bug 150326 – REGRESSION (r187121): Delayed instantaneous animations not honouring ' forwards' fill-mode

• Status: RESOLVED
• Resolution: FIXED
• Component: Animations

[Mario Sanchez Prada]

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

[Mario Sanchez Prada]

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.

[Radar WebKit Bug Importer]

<rdar://problem/23174908>

[Simon Fraser (smfr)]

I don't get the last test case. The page background is animating, but the content suggests the text items should appear/disapper?

[Mario Sanchez Prada]

(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?

[Mario Sanchez Prada]

(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!

[Simon Fraser (smfr)]

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.

[Simon Fraser (smfr)]

Created attachment 263984 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 263984 [details]
Patch

Clearing flags on attachment: 263984

Committed r191540: <http://trac.webkit.org/changeset/191540>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Mario Sanchez Prada]

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.