http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1261164496.1261165987.25225.gz Linux mozilla-central debug test mochitests-1/5 on 2009/12/18 11:28:16 s: moz2-linux-slave08 { >46414 INFO Running /tests/content/svg/content/test/test_animLengthReadonly.xhtml... >++DOMWINDOW == 125 (0xc834f88) [serial = 1176] [outer = 0xa6135c8] >46415 INFO TEST-PASS | /tests/content/svg/content/test/test_animLengthReadonly.xhtml | undefined >46416 ERROR TEST-UNEXPECTED-FAIL | /tests/content/svg/content/test/test_animLengthReadonly.xhtml | undefined - got 4.574999809265137, expected -100 } Looks like randomorange, as the "guilty" changeset is completely unrelated: http://hg.mozilla.org/mozilla-central/rev/cd6ffc0e2a4d

The test itself is here: http://hg.mozilla.org/mozilla-central/file/0e6c2ecbb397/content/svg/content/test/test_animLengthReadonly.xhtml { 36 function main() { 37 // Sanity check: check initial values 38 is(circle.cx.baseVal.value, -100); 39 is(circle.cx.animVal.value, -100); } The second is() check is failing, when checking "circle.cx.animVal.value", so it looks like our animation on that attribute (from="0" to="100" begin="1s; 10s") has already begun. I guess it took us slightly more than 1 second to call the "main()" load-handler? Maybe we should change those time values to be larger (e.g. larger than the mochitest timeout cutoff), so that even under ridiculously-loaded conditions, we won't sporadically reach that time before calling main().

I just pushed a fix for a similar issue in a different test. See bug 474049 comment 101.

Sounds good. I think in some other similar cases of random orange we've just moved the call to pauseAnimations() earlier and use setCurrentTime(0), like you've done in bug 474049 comment 101.

Ok -- I'll do something similar here when I get a chance. Assigning to myself so I don't forget about this. (feel free to steal though)

Landed fix doing what Brian suggested in Comment 3: http://hg.mozilla.org/mozilla-central/rev/7bee3d3a7cf2

For the record, jwatt says we could also have fixed this by listening for "SVGLoad" event, rather than "load", here: > 204 window.addEventListener("load", main, false); The "SVGLoad" event is fired when the <svg> element loads, and hence is synced up with the beginning of the document timeline. The window's "load" event, on the other hand, can be fired a bit later on. (e.g. it waits for all remote scripts, images, etc. to be loaded)