Large GIFs are corrupted when first drawn.

VERIFIED FIXED in mozilla0.9.3



18 years ago
8 years ago


(Reporter: ticmanis, Assigned: pavlov)



Firefox Tracking Flags

(Not tracked)





18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i686; en-US; rv:0.9.1+) Gecko/20010607
BuildID:    2001060721

This is a follow-up to bug 73195 which moved past its original scope. When
loading the given URL and others with large GIFs (and possibly other image
types) for the first time, there are empty bars and vertical stashing. It
happens especially when the connection is a bit slow.  Reloading the image from
the cache will work, as will the normal redraw e.g. on minimize then maximize.

Reproducible: Always
Steps to Reproduce:
1. Clear the cache if necessary.
2. Go to the URL above or any of the following "Next Page" links if you don't
want to clear your cache every time you try it.
3. You should see a corrupted image.

Actual Results:  I saw a corrupted image.

Expected Results:  It shouldn't have been corrupted

This bug isn't new, you'll find a good bit of comments already on bug 73195.

Comment 1

18 years ago
Confirmed on RH 6.2 CVS build 06/08, 05:00 UTC.

As I mentioned in bug 73195, similar things can happen with jpegs, so maybe the
focus of this bug should be broadened.
Ever confirmed: true

Comment 2

18 years ago
Screenshot of rendering problem?

1421x2333 noninterlaced image scaled to 450x700 for display.
I wonder if this is a pixbuf vs. non-pixbuf problem?  On my 7.1 system where
mozilla uses gdkpixbuf I don't see any problems on those pages.

Comment 4

18 years ago
I can't duplicate this in 2001060704 Win98, so it looks like it's Linux-specific.

Comment 5

18 years ago
I tried an 06-08-06 nightly on my Linux system. I have neither Gnome not
gdk-pixbuf installed. It works for me. In fact, I've never seen image
corruption as described. I am using gtk 1.2.10. That might be important.

Comment 6

18 years ago
Hmmmm... maybe. I run SuSE 7.1 with kernel 2.4.2, XFree 4.0.2, and KDE 2.1.2, and I'm definitely getting the corruption.

Comment 7

18 years ago
i see the corruption when loading for the first time. in above URL, whole image
renders as black rectangle, until redrawing forced (minimize/maximize window,
switch desktops, etc).
RH6.2, Xfree86 4.0.3, Ximian GNOME 1.4, gtk+-1.2.10, gdk-pixbuf-0.11.0.
using 2001060521 nightly build. by the way, how do i know if mozilla uses
gdk-pixbuf? no .so libs in mozilla directory seem to depend on it.

Comment 8

18 years ago
resized image. Dup of bug 74313?

Comment 9

18 years ago
Thanks, Asko. Now I'm pretty much convinced that this is a dup of bug 74313
(which was off my radar as it was "fixed" for some time). I've tried Asko's
patch from 74313 (which hasn't yet been checked in) on today's CVS and now can't
reproduce the problem anymore (linux nightly 20010601206 still has the problem -
this is on RedHat 6.2 x86). BTW, his patch ist for .../gfx/src/gtk/XIE.c which
explains a lot.

If interested folks would please try Asko's patch and confirm that it fixes this
bug for them as well, we can dupe this bug and wait for the landing of his fix
in the trunk.

Comment 10

18 years ago
pav sez some of his bugs of 0.9.2 may fix this... targetting for 0.9.3
Priority: -- → P4
Target Milestone: --- → mozilla0.9.3

Comment 11

18 years ago
The test case works for me since bug 86600 was fixed (in favour of bug 74313).
Is anyone still observing problems related to large GIFs? Can anyone still
reproduce the bug on the above URL with current nightlies? If not, we can mark
this one fixed.

Comment 12

18 years ago
seems to be fixed, using 2001062421 linux nightly build.

Comment 13

18 years ago
Marking fixed. 
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
Verified fixed linux build 2001070306
You need to log in before you can comment on or make changes to this bug.