8409 - Animated gif leaves trails

Status: VERIFIED INVALID

(Core :: Graphics: ImageLib, defect, P3)

Description

[Hixie (not reading bugmail)]

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

Comment 1

[Eli Goldberg]

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

Comment 2

[Hixie (not reading bugmail)]

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.

Comment 3

[Hixie (not reading bugmail)]

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.

Comment 4

[pnunn]

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

Comment 5

[pnunn]

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)

Comment 6

[Jay Patel [:jay]]

verified invalid

Comment 7

[Eli Goldberg]

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

Comment 8

[Eli Goldberg]

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

Comment 9

[Hixie (not reading bugmail)]

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.

Comment 10

[pnunn]

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