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

RESOLVED FIXED in mozilla33

Status

()

Core
CSS Parsing and Computation
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: birtles)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
mozilla33
x86_64
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8443884 [details]
testcase

Assertion failure: !IsPaused() || aTime >= mPauseStart (if paused, aTime must be at least mPauseStart), at layout/style/AnimationCommon.h:335
(Reporter)

Comment 1

4 years ago
Created attachment 8443885 [details]
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
Created attachment 8445658 [details] [diff] [review]
Don't let refresh driver time go backwards when changing timers

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)
https://hg.mozilla.org/mozilla-central/rev/ccdb8d43db9f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.