Closed Bug 1028511 Opened 10 years ago Closed 10 years ago

Assertion failure: "if paused, aTime must be at least mPauseStart"

Categories

(Core :: CSS Parsing and Computation, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: jruderman, Assigned: birtles)

References

Details

(Keywords: assertion, testcase)

Attachments

(3 files)

Attached file testcase
Assertion failure: !IsPaused() || aTime >= mPauseStart (if paused, aTime must be at least mPauseStart), at layout/style/AnimationCommon.h:335
Attached file stack
I spent some time tracking this down and it appears the problem arises because times from the refresh driver can go backwards putting the time recorded for pause start in BuildAnimations *later* than the time used in FlushAnimations. This seems to occur when we create the window because inside the refresh driver when we switch from the throttled-rate timer back to the regular-rate timer. I think we should probably make the refresh driver guarantee that time never goes backwards by clamping times if necessary. This still won't be true when the refresh driver is under test control but long-term I hope to fix that too and make sure in that case too times never go backwards.
Assignee: nobody → birtles
Status: NEW → ASSIGNED
I've spent a few hours trying but I can't seem to turn the attached test case in a crashtest that fails correctly. For now, though, this patch fixes the problem for me. Basically, as described in comment 2, the popping up a window and closing it again, causes us to switch timers which leads to the refresh driver time going backwards just briefly but in the interim time we sample the paused animation at a time before its pause start. This patch simply clamps the refresh driver time so that when we change timers we don't go backwards. This should be sufficient because the only other times we update the refresh driver time are when we are under test control (which needs to be fixed so that it also never goes backwards but that's a whole lot of separate work) or when we get a tick in which case we use the current timestamp which should always be >= the previous refresh time.
Attachment #8445658 - Flags: review?(vladimir)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: