Closed
Bug 571016
Opened 15 years ago
Closed 15 years ago
test_smilReset.xhtml fails intermittently with An attempt was made to use an object that is not, or is no longer, usable
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
FIXED
People
(Reporter: hsivonen, Unassigned)
References
()
Details
(Keywords: intermittent-failure)
64602 INFO Running /tests/content/smil/test/test_smilReset.xhtml...
64603 INFO TEST-PASS | /tests/content/smil/test/test_smilReset.xhtml | should be paused by <svg> load handler
64604 INFO TEST-PASS | /tests/content/smil/test/test_smilReset.xhtml | should be paused at 0 in <svg> load handler - 0 should equal 0
64605 ERROR TEST-UNEXPECTED-FAIL | /tests/content/smil/test/test_smilReset.xhtml | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - uncaught exception: [Exception... "An attempt was made to use an object that is not, or is no longer, usable" code: "11" nsresult: "0x8053000b (NS_ERROR_DOM_INVALID_STATE_ERR)" location: "http://mochi.test:8888/tests/content/smil/test/test_smilReset.xhtml Line: 32"] at :0
64606 INFO SimpleTest finished /tests/content/smil/test/test_smilReset.xhtml in 101ms
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276078173.1276078715.29515.gz
This was after landing bug 552938, which changed how the SVG load event fires. However, the problem went away with the next tinderbox cycle.
Comment 1•15 years ago
|
||
Comment 3•15 years ago
|
||
So bug 552938 potentially delays the firing of our SVG load event, right? Before we had...
> nsEventDispatcher::Dispatch(content, ctx, &event);
...while now we have...
> nsCOMPtr<nsIRunnable> event = new nsHtml5SVGLoadDispatcher(content);
> nsEvent event(PR_TRUE, NS_SVG_LOAD);
> if (NS_FAILED(NS_DispatchToMainThread(event))) {
... followed by (when the nsHtml5SVGLoadDispatcher gets processed):
> nsEventDispatcher::Dispatch(mElement, ctx, &event);
So, the "Dispatch" call will be later than it used to, depending on how long it takes the main thread to get to our nsHtml5SVGLoadDispatcher. Could that be causing the problem? Perhaps we trigger the js function "main()" (from the window's load-handler) before the SVG DOM is loaded, and that puts us in an inconsistent state when we make the first call to an SVG API?
Comment 4•15 years ago
|
||
(In reply to comment #3)
> ...while now we have...
>
> > nsCOMPtr<nsIRunnable> event = new nsHtml5SVGLoadDispatcher(content);
> > nsEvent event(PR_TRUE, NS_SVG_LOAD);
Sorry, that was a copy-paste fail in code copied from bugzilla's diff-viewer. That second line (with "nsEvent event") is from old code (accidentally copied from left side of the diff viewer) & I didn't mean to include it there.
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 6•15 years ago
|
||
(In reply to comment #0)
> This was after landing bug 552938, which changed how the SVG load event fires.
> However, the problem went away with the next tinderbox cycle.
This seems to have a fairly high rate of failure... Perhaps we should back out bug 552938 for now, to stop the orange, pending more investigation?
Version: unspecified → Trunk
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 8•15 years ago
|
||
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276125583.1276126261.26196.gz
Linux mozilla-central opt test mochitests-1/5 on 2010/06/09 16:19:43
s: moz2-linux-slave02
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 10•15 years ago
|
||
(In reply to comment #0)
> This was after landing bug 552938
Just backed out that bug -- this randomorange should hopefully be fixed in tinderbox cycles after the backout.
Comment 11•15 years ago
|
||
No instances of this randomorange during the 9 tinderbox-cycles that have happened since the backout. Calling this fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•15 years ago
|
||
Is animationsPaused() supposed to return true if animations haven't started, yet?
It seems that the NS_ERROR_DOM_INVALID_STATE_ERR comes from the animation being in nsSMILElementState STATE_STARTUP when calling anim.getStartTime(), but in that case, why didn't svg.animationsPaused() return false?
Reporter | ||
Comment 13•15 years ago
|
||
Over in bug 552938, I tried to block and unblock onload, which indeed succeeded in making the SVG load event always fire before the document's load event. However, after that change, this bug still manifests itself on try.
Any clues?
Comment 14•14 years ago
|
||
Ok -- so what's happening here is, we've started the SMIL timeline, but we haven't had a SMIL sample yet. So even though we're after time t=0, we haven't yet noticed that our animation element (with begin="0") has started.
Til now, I'd been thinking that we did a synchronous sample with SVGLoad, but it looks like we don't -- we just kick off the timeline with a Begin() call on the TimeContainer (in nsSVGSVGElement::PreHandleEvent), and then we wait for the first sample to *actually* resolve begin times etc.
For now, the simplest workaround/fix is to simply add this to the test:
> svg.setCurrentTime(0);
before the first getStartTime() call. This will force a synchronous animation-sample, which lets us notice that our animation element has started.
Comment 15•14 years ago
|
||
FWIW, I think the reason this didn't cause problems in other tests was that other tests generally call setCurrentTime earlier on. (before calling things like getStartTime that fail if we've never sampled, at least)
I'm not immediately sure why we never saw this bug until bug 552938 landed, though... maybe it's just that we used to have enough time between SVGLoad & window.load to fit a sample in there, and bug 552938 significantly reduced the time between them (in particular, now they'll be handled back-to-back some significant percent of the time)
Comment 16•14 years ago
|
||
(In reply to comment #14)
> So even though we're after time t=0
er, to be correct, that should be "at time t=0", not "after time t=0" (since we paused animations on svgload, which is time 0)
Comment 17•14 years ago
|
||
I filed bug 580098 on the underlying bug here. Once that's fixed, we should be able to remove the "svg.setCurrentTime(0)" workaround introduced in Henri's fix on bug bug 552938.
Comment 18•14 years ago
|
||
Just pushed the fix for bug 580098, & reverted the setCurrentTime workaround, in bug 580098 comment 5.
Assignee | ||
Updated•12 years ago
|
Keywords: intermittent-failure
Assignee | ||
Updated•12 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•