Closed Bug 615002 Opened 15 years ago Closed 15 years ago

"ABORT: Got a regular sample during startup state, expected an end sample instead"

Categories

(Core :: SVG, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: jruderman, Assigned: birtles)

References

Details

(Keywords: assertion, testcase)

Attachments

(2 files, 1 obsolete file)

###!!! ABORT: Got a regular sample during startup state, expected an end sample instead: 'mElementState != STATE_STARTUP || aEndOnly', file content/smil/nsSMILTimedElement.cpp, line 506
Assignee: nobody → birtles
Status: NEW → ASSIGNED
Attached patch Patch v1a (obsolete) — Splinter Review
Proposed patch. As described in the comment in the patch, the problem occurs when we register a milestone before t=0s (t=-2s in this case) and then get re-bound to the tree which sends us back to the startup state.
Attachment #495730 - Flags: review?(dholbert)
Comment on attachment 495730 [details] [diff] [review] Patch v1a One nit on the test... >+++ b/content/smil/crashtests/615002-1.svg >+ document.documentElement.appendChild(a); >+ // Allow time for a sample before finishing >+ setTimeout( >+ function() { document.documentElement.removeAttribute("class"); }, 1); >+} I don't think we actually guarantee that a SMIL sample will happen before that setTimeout fires, right? And even if that does reliably work, it's still best to avoid unnecessary setTimeouts when better alternatives are available. I'd suggest: - adding setCurrentTime(0) to force a synchronous sample before clearing reftest-wait ...or... - using some combination of "window.mozRequestAnimationFrame()" and probably MozAfterPaint (see mxr for sample usage) r=dholbert with that test-fix.
Attachment #495730 - Flags: review?(dholbert) → review+
(In reply to comment #2) > And even if that does reliably work, it's still best to avoid unnecessary > setTimeouts when better alternatives are available. I'd suggest: > - adding setCurrentTime(0) to force a synchronous sample before clearing > reftest-wait Fixed. Thanks Daniel!
Attachment #495730 - Attachment is obsolete: true
Attachment #496007 - Flags: review+
Attachment #496007 - Flags: approval2.0?
Requesting approval to land. Fixes fatal assertion. Includes test.
Whiteboard: [needs approval]
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [needs approval] → [needs landing]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: