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.
*** This bug has been marked as a duplicate of 206709 ***
sorry about that, wrong bug.
Confirming on WinXP 2003060608.
The same problem also exists on Linux (Mandrake 9.1 and nightly 20030611).
This bug is now also part of Mozilla 1.4 final.
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.
Created attachment 127403 [details] 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.
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.
Created attachment 128270 [details] [diff] [review] 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 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.
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.
*** Bug 212093 has been marked as a duplicate of this bug. ***
Comment on attachment 128270 [details] [diff] [review] move limit check to HaveDecodedRow a=mkaply
Please add fixed1.4.1 keyword when checked in.
Is this being fixed in 1.5 as well?
tor tells me it's checked into trunk and 1.4 branch, so no issue there.