208622 - Some animated GIF images don't display properly

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Jure Repinc (JLP)]

If you go to the above URL you can see 4 blue squares under Contents. These
animated GIF images (http://www.linuxgazette.com/gx/dennis/qbub.gif) should
display as question marks in a speach bubble just like on this image:
http://www.linuxgazette.com/gx/dennis/qbubble.gif.

I'm using Mozilla 2003060608 on Windows XP Pro with SP1.

Comment 1

[Olivier Cahagne]

*** This bug has been marked as a duplicate of 206709 ***

Comment 2

[Olivier Cahagne]

sorry about that, wrong bug.

Comment 3

[Jason Barnabe (np)]

Confirming on WinXP 2003060608.

Comment 4

[Jure Repinc (JLP)]

The same problem also exists on Linux (Mandrake 9.1 and nightly 20030611).

Comment 5

[Jure Repinc (JLP)]

This bug is now also part of Mozilla 1.4 final.

Comment 6

[Michael Sinz]

I can confirm that this is happening on certain types of Anim GIFs with Mozilla
1.4 on Mac OS-X, Linux, and Windows.  (Win2K and WinXP)

For an example, go to http://www.sinz.org/Palm/index.html and look at the
Pente0.gif that is rendered incorrectly.

http://www.sinz.org/Palm/Pente0.gif to load it directly...

This is not the case on 1.3 and 1.3.1 nor other older offshoots.

Comment 7

[Michael Sinz]

Attachment: Anim-GIF that renders incorrectly on Mozilla 1.4

Here is my Anim-GIF that renders incorrectly.  The problem is most likely
caused by the use of some advanced GIF sub-area features in the multi-frame GIF
images.  This used to work.  I am sorry I did not notice this before but I did
not have a need to look at my Palm web page for quite some time and today I
just happened to need to do so and noticed the problem.

I have tried older builds that I had still on my system (I don't have a very
fast net connection, so downloading others is currently out of the question)
but I noticed this in the Mozilla 1.4 final and Mozilla 1.4b release for Linux
x86, Mac OS-X, and Windows (2K and XP).  I have verified that it did not happen
in Mozilla 1.3.1 on any of those platforms.

Comment 8

[tor]

For the testcase image this is caused by the checkin for bug 199701, which
was supposed to guard against illegal color index values.  Unfortunately
this file has a colormap of two entries, but is using an index value of
two (what would be the third entry) as the transparent index.

Taking bug.

Comment 9

[tor]

Attachment: move limit check to HaveDecodedRow

Patch backs out the old limit check and moves it to HaveDecodedRow.
Additionally folds the RGB and BGR cases to reduce code size.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 128270 [details] [diff] [review]
move limit check to HaveDecodedRow

nits:

Is format == gfxIFormats::BGR the only possibility for
XP_WIN/XP_OS2/XP_BEOS/PHOTON?  Those can never be using ::RGB?	If so, does
gfxIFormats really need to have RGB and BGR as separate values?

Is that list of OS's really shorthand for something else (some HW attribute)? 
If so, should we use that list in one spot to set a GFX_HW_IS_BGR or whatever
define instead?

BTW, I've hacked on some of this code before; looks good to me too.

Comment 11

[tor]

In theory imglib2 should be querying gfx to inquire what format it would
like the images in, but in practice all the decoders hardcode this knowledge.
Changing that would be the subject of another bug.

Comment 12

[tor]

Checked in.

Comment 13

[tor]

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

Comment 14

[Mike Kaply [:mkaply]]

Comment on attachment 128270 [details] [diff] [review]
move limit check to HaveDecodedRow

a=mkaply

Comment 15

[Mike Kaply [:mkaply]]

Please add fixed1.4.1 keyword when checked in.

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Is this being fixed in 1.5 as well?

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

tor tells me it's checked into trunk and 1.4 branch, so no issue there.