The test page: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/jack8.gif ...is an animated GIF. In Mozilla, the twirling baton leaves trails, as if each frame is drawn upon the other instead of replacing the other. (Note. If this is correct behaviour and the animated gif is wrong, then this bug should be reassigned for evangalisation. The GIF originally comes from http://www.ea.com/ . You can see it under "American Made".)

[This also occurs on Communicator 4.6/Mac, but works properly on IE 5/Win32.]

This also occurs in Opera 3.51. Someone with an animated GIF editor should check whether what is happening is acually correct or if this really is a bug.

Correction: Opera 3.51 uses the first frame as a background, and renders the other frames on top. Mozilla renders each frame on top of each other, until the end of the animation, and then it cleans up and renders the first frame afresh, before starting over.

This sounds like a duplicate of a bug# that escapes me at the moment. Currently we don't support all frame background erase options. -pn

After looking at this image with several different viewers, it seems to me the problem is partially with the image. The editing control block in this file specifies "remove by the previous image". The netscape browser and GIFConstructionSet view the animated image with trails. If the image is changed so the editing control block specifies "remove by background", both GIFConstructionSet and netscape browser view the animated image. This setting of "remove by background" is the recommended setting for gif animations. The known bug I mentioned before does not appear to be a problem here. This problem had to do with a mixture of editing control blocks set to "leave as is" and "use previous image". (reference: humbird.gif)

verified invalid

[Returned bug to RESOLVED/INVALID; please do not mark my bugs Verified for me. Thank you.]

Okay. I've done my due diligence, per the GIF 89a spec, "Restore to Previous" tells the user agent that: The decoder is required to restore the area overwritten by the graphic with what was there prior to rendering the graphic. Thus, we are displaying the image pursuant to the specification, and IE is deviating. (Ian: Nobody does such evangelism within Netscape that I know of, but you're certainly welcome to contact the webmaster for EA and inform them that the GIF image in question is invalid and correspondingly displays improperly.)

Well, they no longer use that gif. (I thought that might happen, its why I took a snapshot and put it on my site...) I suggest we forget about it. If Communicator4 got it right too then most people will notice the problem quite soon and not blame us for changing the rules of the game as they are doing with our correct CSS, HTML, DOM,... implementations. So evangelisation should not be particularily needed in this case: only IE gets it wrong.

*** Bug 22607 has been marked as a duplicate of this bug. ***