277653 - Random jumping around of images in dhtml game

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P1)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Martijn Wargers (dead)]

Attachment: image for testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: Testcase

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

Comment 3

[Martijn Wargers (dead)]

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.

Comment 4

[Martijn Wargers (dead)]

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

Comment 5

[Brent Silby]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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...

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Fixed by patch in bug 244366.