Closed Bug 588287 Opened 14 years ago Closed 14 years ago

"ASSERTION: Sample time should not precede current interval" with animation

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- final+

People

(Reporter: jruderman, Assigned: birtles)

References

Details

(Keywords: assertion, testcase)

Attachments

(2 files, 2 obsolete files)

Attached image testcase
###!!! ASSERTION: Sample time should not precede current interval: 'aContainerTime >= beginTime', file content/smil/nsSMILTimedElement.cpp, line 603 ###!!! ASSERTION: Expecting non-negative active time: 'aActiveTime >= 0', file content/smil/nsSMILTimedElement.cpp, line 1739 My fuzzer has been hitting this assertion for months, but this is the first time it has managed to create a reduced testcase for it.
I'll take this. My guess is that something's not getting cleaned up when we demote the newly created <svg> element from an outer <svg> to an inner <svg>. It would be worth testing a variation on this test case too where the already active animation is re-parented to a more recently created outer svg container.
Assignee: nobody → birtles
Status: NEW → ASSIGNED
blocking2.0: --- → ?
Attached patch Proposed patch v1a (obsolete) — Splinter Review
Ok, here's a stab at a fix for this. Note that in the test case, the created <g> element is not in the SVG namespace and so the nested <svg> element (which is in the SVG namespace) serves as an outermost <svg> element (since its parent is not an SVG element is doesn't look any further up). The problem then is that the animation is re-parented to a younger time container and our assertion fails because time seems to go backwards without a backwards seek. So this patch detects when we're re-parented to a younger time container (or at least a time container whose current time precedes the beginning of our current interval) and performs a local rewind on the element in that case.
Attachment #477016 - Flags: review?(dholbert)
Comment on attachment 477016 [details] [diff] [review] Proposed patch v1a The crashtests need "reftest-wait" to make sure the setTimeout fires before we've dismissed the test. Otherwise looks good! Sorry for the delay on this.
Attachment #477016 - Flags: review?(dholbert) → review+
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [needs review]
Whiteboard: [needs patch-tweak, and then needs landing]
Attached patch Patch v1b, r=dholbert (obsolete) — Splinter Review
Add reftest-wait to test cases
Attachment #477016 - Attachment is obsolete: true
Attachment #480811 - Flags: review+
Oops, the removing of the reftest-wait was on the wrong <svg> element. Fixed, I hope.
Attachment #480811 - Attachment is obsolete: true
Attachment #480838 - Flags: review+
Whiteboard: [needs patch-tweak, and then needs landing] → [waiting to checkin]
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
Whiteboard: [waiting to checkin]
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: