Closed Bug 571016 Opened 14 years ago Closed 14 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)

Product:
Core
Component:
SVG
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hsivonen, Unassigned)

References

(
URL
)

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.
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?
(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.
(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
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
Blocks: 552938
(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.
No instances of this randomorange during the 9 tinderbox-cycles that have happened since the backout.  Calling this fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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?
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?
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.
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)
(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)
Depends on: 580098
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.
Just pushed the fix for bug 580098, & reverted the setCurrentTime workaround, in bug 580098 comment 5.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.