When playing that game the images sometimes appear in the wrong place. It looks like they're sometimes jumping around. Older Mozilla versions don't do this, so it's a bug. this bug occurs with a lot more games on that site, by the way. I can't see this bug with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040809 Firefox/0.9.1+ 6:48am But I can see the bug with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040810 Firefox/0.9.1+ 6:49am http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-09+06%3A00%3A00&maxdate=2004-08-10+07%3A00%3A00&cvsroot=%2Fcvsroot I'll attach a testcase. I don't see this bug occuring on my winxp machine.

Click on the addtimer() button to start the animation. I can see the bug occuring even with one timer, but it is much easier noticeable when you have pushed the button 3 or 4 times. I've made a screen recording, in case you don't see the bug: http://martijn.heelveel.info/test/mozilla/jumping_around.avi

Hmm, now with just one click I can easily see the bug. I think this could be a regression from bug 230170, by the way, looking at the checkins of that period.

Correction from comment 0: I can also see this bug on my winxp machine.

Probably worth mentioning that these games use image clipping to move between animation frames in the gifs. The script clips to the correct part of the gif, and then immediately shifts the x,y pos of the gif to the correct position to show an animated image. It looks like Moz is updating the image immediately after the clip, and then re-updating after the x,y pos are updated.

The original regression is almost certainly due to some sort of interaction between bug 230170 and painting, yes. In a current build I can get this testcase to behave if I not only remove the bug 230170 patch (do immediate processing of the restyle event), but wrap each such processing in a view update batch. This last is odd; I don't really see why it would be needed. Interestingly, if I flush out layout after setting the style then the problem also disappears (though the animation gets slower, of course). Taking. I'm going to see what I can find here.

Some more experimentation leaves me _very_ confused. I tried expanding on my patch to bug 244366 by flushing reflows right before painting too. That fixed the testcase in this bug. It did NOT fix the game at <http://www.def-logic.com/replicator/replicator.html>. In fact, when playing that game there are no reflows to flush when we get an NS_PAINT event... The game _is_ fixed by doing style changes individually, each in a view update batch. But we really don't want to do this...

Ok, I found a bug in my attempt to patch bug 244366. With that bug fixed, the jumping disappears on both the testcase and the game. The patch still has issues, of course, but at least it's the right general idea.

Fixed by patch in bug 244366.