[Webkit-unassigned] [Bug 150326] New: Delayed instantaneous animations not honouring ' forwards' fill-mode

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 19 05:07:25 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=150326

            Bug ID: 150326
           Summary: Delayed instantaneous animations not honouring '
                    forwards' fill-mode
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Animations
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mario at webkit.org
                CC: cgarcia at igalia.com, dino at apple.com, hyatt at apple.com,
                    mrobinson at webkit.org

Created attachment 263471
  --> https://bugs.webkit.org/attachment.cgi?id=263471&action=review
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151019/d4acec3c/attachment.html>


More information about the webkit-unassigned mailing list