[Webkit-unassigned] [Bug 48161] New: animations/suspend-resume-animation.html is flaky

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 22 16:40:32 PDT 2010


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

           Summary: animations/suspend-resume-animation.html is flaky
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jparent at google.com
                CC: oliver at apple.com, cmarrin at apple.com


Background:

This tests that suspendAnimations and resumeAnimations work properly.

It starts an animation, suspends it on setTimeout(500), and resumes it on setTimeout(1000).  To test that the suspend works, it checks the animation at .6 and .9 seconds, and then again at 1.5 seconds to test that resume worked:
      // [animation-name, time, element-id, property, expected-value, tolerance]
      ["rotate", 0.6, "box", "webkitTransform", [1,0,0,1, 200, 0], 30],
      ["rotate", 0.9, "box", "webkitTransform", [1,0,0,1, 200, 0], 30],
      ["rotate", 1.5, "box", "webkitTransform", [1,0,0,1, 400, 0], 30],

Due to the timeouts involved, this can be flaky (we are seeing it fail about 2% of the time with values of 231 and 431, 1 pixel outside the tolerance).

Rather than tweak the tolerances more, I was thinking it might make more sense to re-write the test to more explicitly test that suspend and resume work, rather than relying on the animation values.  So, something like:
At 0.6 and 0.9, rather than test for being at 200, test that the value is the same at both times (aka, it is definitely suspended), and that the value is > 0 (it did indeed start), and less < the end value (it hasn't ended).
At 1.5, rather than test for being at 400, test that the value is greater than it was at 0.6/0.9 (aka, it did resume).

Does that sound ok, or would that be losing test coverage?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list