[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