REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-opt-unittest-reftest/build/reftest/tests/layout/reftests/svg/smil/mapped-attr-vs-css-prop-1.svg | http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268794062.1268794888.23764.gz

Also failed on Mac. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268794085.1268795214.24665.gz

and again on mac: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268797345.1268798680.32080.gz I'll mark the test as random for now & investigate. One clue: so far, the failures have been opt-only (though there have been green opt cycles too). I'm guessing that the final setCurrentTime (in setTimeAndSnapshot) isn't flushing correctly for mapped-attrs, and that leaves the reftest snapshot out-of-date.

(the test is set up as a grid) * All three logs so far are too dark @ 1st row, 4th col * The log from comment 1 is also too dark @ 1st row, 3rd col. I think I know what's going on. As described in the log, the attributeType="XML" animation should affect the base value of the attributeType="CSS" animation. However, if our random hashtable-iteration-order has us compose the attributeType="CSS" animation first, then it will be using out-of-date computedStyle for its base value. So, to fix this, we need to make sure to compose mapped-attributes before their CSS counterparts.

(In reply to comment #3) > I think I know what's going on. As described in the log er, I mean "as described in the test"

Marked test as random for now: http://hg.mozilla.org/mozilla-central/rev/9f009849b690

Re-enabled test with (I think) a workaround: http://hg.mozilla.org/mozilla-central/rev/1024d83e7661 I tweaked the onload handler, adding a (hacky) duplicate setCurrentTime() before the setTimeAndSnapshot call. The new setCurrentTime() call will force a synchronous sample, which will update the animated value of the mapped attribute, so that it's up-to-date when we get to the call to setTimeAndSnapshot (and the sample that happens there). So if comment 3 is correct, this should work around the problem.

Updating bug summary with the actual problem here (per comment 3 / bug 501183 comment 1), and unassigning myself for now.