From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: 2001032304 Loading Mozilla.org the first time doesn't correctly render the mozilla- banner.gif. After scrolling the image offscreen of moving another window over it, it is shown correctly. Reproducible: Always Steps to Reproduce: 1. delete profile or cache directories 2. Start Mozilla 3. go to http://www.mozilla.org, and watch header-gif 4. move another window over the gif, or scroll gif out of view, and show it again, it now shows correctly. Actual Results: Gif not rendered properly Expected Results: Gif completely rendered. Seen this on two computers (2001032304, and home-build with newcache en libpr0n). I completely deleted my profile, reloading (F5/Ctrl-F5) or restart mozilla shows the gif correctly.

Confirmed on WinNT 2001032304.

libpr0n bug (it's on in that windows build already)

Correct Boris, I ment to suggest we add this bug to the libpr0n tracking bug...I will do that if it has not been done already.

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

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

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

A method to reproduce this (Build ID: 2001032604): 1. take this picture from the Web: http://office.altkom.com.pl/mozilla/logo.png or from the attachment 28808 [details] ) 2. Place it locally on your HDD (when opening it remotely doesn't work every time) 3. Try to open it with File->Open Its display's corrupted. However, if you switch to another window and switch back to mozilla, the image will display correctly without even having to to be reloaded! Immediate following reloads of the image don't show the corruption. However, if you wait a considerable amount of time (a couple of minutes maybe) then, after reloading, it will display corrupted again. This problem occurs not only with PNGs, I've also seen it happen with JPGs and GIFs (the one on Google's frontpage for example), but couldn't reproduce it on remote pics - they don't corrupt the second time, sometimes even never again... I also experienced crashes when displaying the corrupting pic (Talkback IDs: TB28277471E - when opening locallly TB28276985E - when opening locallly TB28309466H - when opening from http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28808 ), but those may be unrelated, I noticed similar crashes with this build elsewhere. I tested it with today's Linux builds, but all worked fine.

Shouldn't this bug's component be changed to "Compositor"? That problem occurs regardless of image type and only when displaying on screen, not during loading.

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

changing summary per comment from Aleksander Adamowski. confirmin' same behavior.

could also be blocking bug 73328 (Throbber is broken)

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

Confirmed on Windows 98-win32 Build ID: 2001032704 Was not present in build from March 18: 20010318?? (I update once per week on Sundays and image loading was working fine until my most recent update this week)

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

While there is an easy work-around for this, it is still making it REALLY annoying to browse with mozilla. I am probably going to have to roll back to the last version that didn't have this bug and wait for a fix to come through...

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

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

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

The workaround for this bug, mentioned earlier, doesn't fix the problem in bug 74235. Scrolling the images in http://hadrian.org/public/ off screen, or covering them with another window, does not cause Mozilla to display them when the browser window is uncovered or scrolled to its original viewing position -- they remain completely blank. I'm seeing the corrupted display of other graphics, with work-around, elsewhere though. Linux nightly 2001033105.

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

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

John Hayward-Warburton: Can you reproduce it on latest Linux builds? I don't see anything wrong in http://hadrian.org/public/ I'm using Mozilla 2001040208 (Linux-i686).

This particular bug might (?) be something different. Resizing the image (within the IMG) tag tickles this one. Please see bug 74235 and my new testcase at http://johnwarburton.net/nopic/

On Windows 95, build 2001032804, MOST images do not display correctly. I have found a very easy way to get them to render correctly... just drag the image a bit by holding down the left mouse button on the image and moving the mouse a bit.

I'm also noticing 90% reproducible crashes when i place the file http://office.altkom.com.pl/mozilla/logo.png locally on my HDD, make copies of it with different names (logo2.png, logo3.png, logo4.png) and open one of them instantly after starting Mozilla (through File->Open), before loading any web page. Win32 talkback build 2001040204. Talkback ids: TB28591438Y TB28591412K

Since the images started becoming corrupted I've also noticed two other things: http://www.dilbertzone.com/comics/dilbert/archive/ If you rightclick and view the daily comic in a new window and try and print it will shrink the image to the point where it's illegible. This started happening when the images weren't displaying properly. Second. When I installed build 2001040304 today and went to checkout the above site the images that I had set as blocked were still blocked but 100% visable on the page. When the corrupted images first appeared blocked images would show up as a black box with white lines through it and often had flashing parts within the blocked area. Even unblocking and reblocking the image made no difference. The blocked images were still 100% visable.

patch from Kevin McCluskey (kmcclusk@netscape.com) to fix this bug. r=pavlov

sr=jst, for what it's worth.

fix checked in

Still seeing some corruption (though not as much) on 2001040409 Linux

Looks good now on Windows 95 with build 2001040404. I notice some chuffyness on progressive rendering of PNGs, but Im pretty sure that is material for a separate bug.

Resized images (width/height in <IMG...> tag not in agreement with actual image size) still do not display at all on X Mach64 display (but are fine on S3 Trio3D/2X) with Linux build 2001040409, X-4.0.3.

Several animated GIFs look broken on build 2001040409 (and earlier versions of the new Image library), Linux (both my displays). See, for example, http://silversurfers.uk.com/includes/ad_here.gif Each layer doesn't appear to be offset in the correct place, and the blank layers between each 'flash' of text don't work correctly.

John: You should probably best check if those problems are already filed, and otherwise post those problems as new bugs. This one is for images corrupted on first draw, there are animated gif and Linux problems elswhere. The problems you mention seem OS specific and should be filed for that platform/OS to get the attention they deserve.

minimal amount of coruption still present on linux 2001040414. Usually shows up in large pictures or pictures loading from low bandwidth connections, when they load top to bottom (not progressively). In such cases I see 1-pixel wide white horizontal lines.

Still seeing problems on Win2k. Load this page (http://www.ultimatezip.com/) and check out the screenshots on the right side. They seem to partly load, but then they fully appear if you mouse over them (?). Weirder still, there's no JavaScript "mouseover" associated with those images.

I can reproduce Alex Bischoff's report exactly on Win 98 (2001040504).

I can also reproduce Alex Bischoff's report on WinNT (2001040504) Also probably a better example page is http://www.themes.org because it has dozens of images all over the place. Just go there and refresh the page a couple of times and random images will not completely draw. This could be a cache issue since resizing will not force the images to draw.

Two, three additional data points. 1. http://www.ncmag.com/2001_03/toc.html Using win32 2001041004 shows two patterns: image of the magazine's cover is distorted (black lines) until the image is clicked. I was able to reproduce this over and over, yet now (with several Mozs open) the pattern has changed: image is initially distorted as above but then clears itself. Using linux 20010401 shows one pattern: no image at all. 2. http://www.ibm.com Big Blue's logo image (upper left) blinks on both builds mentioned above, with the additional problem that on linux the image is only half drawn from top to middle.

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

marking this fixed. there are plenty of other open bugs about animated images and linux scaled drawing bugs.

It seems like this has reappeared. Build 2001050104, Win98. When I visit http://www.comics.com/comics/luann/, the Luann comic will sometimes draw with a few black lines near the top. Clicking on the image makes the lines go away.

Confirming on win32-talkback build 2001050104 A few black lines at the top. As previously with this bug scrolling image offscreen and back results in image being displayed properly.

this isn't that bug. there are numerous new bugs about nothing drawing right the first time around due to a bunch of new bugs in the view manager I expect. re-resolving fixed.

This is still happening to me on build 20010505 Win98. The browser reliably messes up this page: http://ien.virtualave.net/ob/ Stop marking this fixed! If there is another bug for this error, mark it as a duplicate of this one. We need this bug to have the mostfreq status.

I also can confirm this. The pic is splitted in 3 rows and the upper is some times drawn with horizontal lines. After clicking on the image all displays fine.

If there's a problem with libpr0n, maybe we might to better seeing if when it's removed if this will go away. *sigh* No offense to anyone... Everytime something like this happens somebody does something else to slow down painting, disabling the eager paint is causing some nasty slow downs. (I fear we are heading the wrong way on this)

Ever since libpr0n was added, we've had nothing but problems. IMNSHO, it needs to go. Away. Far, far away.

No problem, we'll reopen all the bugs it fixed, and you can fix them in the old code. Or try to. If you have something constructive to say, do it.

Look, this bug is fixed. Go look at bug 74129 if you want to cry about things not drawing.

Saari, Pavlov: the problems I've been seeing in the latest builds don't seem to be the same as what's described in bug 74129. I'm seeing problems with images with black stripes through them, on the first time they're loaded. As far as I know, there's no "damage" to the view. Is that really bug 74129, or something else?

ok, fine, i'll reopen this and look into it in greater detail.

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

This has nothing to do with bug 74129 and everything to do with bug 73195. Instead of being rude to testers and closing bugs, why don't you Netscape people work on fixing the problem? I guess AOL has had an effect on you after all.

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

I can be wrong, but I belive all corrupted pics are with <a href>...

Eugene, I don't think you're right, see bug 79379, which is a duplicate but it doesn't have <a href> at all.

Hoping to maybe clear up on which problems are still there and which aren't... I went through the various examples in these comments on win98, 2001-05-08-17-trunk. This is what I see, YMMV: http://www.mozilla.org banner : ok, no attachment 28607 [details] sorta problems. Attachment 28808 [details] : ok. Crashes on rendering images as described on March 26th by Aleksander Adamowski : haven't seen this since 20010402. http://hadrian.org/public/ : ok. http://johnwarburton.net/nopic/ : ok. http://www.dilbertzone.com/comics/dilbert/archive/ : comic always corrupts on shift-reload. http://silversurfers.uk.com/includes/ad_here.gif : ok. screenshots at http://www.ultimatezip.com/ and http://www.themes.org/ : ok. http://www.ncmag.com/2001_03/toc.html : corrupts. http://www.ibm.com/i/v10/m/en/lanim.gif : ns47 and ie55 show the animation once, mozillla repeats it. http://www.comics.com/comics/luann/ : corrupts occasionally. http://ien.virtualave.net/ob/ : can't get it to stay corrupt when loading whole page, but shift-reloading only the image http://ien.virtualave.net/ob/cc.gif does leave the black lines in top 1/3. attachment 32248 [details] seems reliable enough for testing. Shift-reload to get progressive display; All scans don't seem to hit the top lines. The remaining black lines are slightly differently placed each time. Why is the image area mostly filled with black during the progressive rendering in the first place?

right... "Interlaced GIFs often finish rendering with stripes" is covered by bug 73972, "Mozilla repeating animation of images when it shouldn't" is bug 75828, black background in interlaced rendering is covered by bug 76703. That's all the problems I see, so I guess this bug is useless and too confused to keep.

For me, url http://johnwarburton.net/nopic/ is not fixed. The resized image refuses to display on the ATIMach64 card; the Trio S3/2X card does work. Most odd, but this is still the original problem. I believe another bug has been opened for this?

Ermmmm... Tuukka, I don't agree. It happens for non-interlaced GIF's too, especially when they are large and also are coming from a slow server. Seems like the renderer keeps rendering without waiting for the necessary data to arrive, or something like that. I don't think it has to do with cache, since when I shift-reload from the proxie's (!) cache the image works.

I saw it today at http://forex.mdmbank.com/finance/forex/info.htm?cur1=EUR&cur2=USD - every minute updated image. Reload it (with shift, I had already filled a bug for this) and you will probably see it some time.

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

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

This may or may not be related. Loading the weathermap from http://www.weather.com/maps/maptype/forecastsusnational/useveningforecast_large.html is always corrupted when drawn the first time - when the image is being drawn incrementally. The last 10 or so pixel rows are drawn correctly. When the image is being drawn from cache (either Mozilla's own, or a local (fast) squid cache) the image is rendered correctly. (System is linux RH7.0, Mozilla build 2001050521 = 0.9, on a 300Mhz K6, display is ATI rageII graphics)

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

Pav sez: this is a known dup of one of his 0.9.1 bugs... marking target as such.

ok. i've checked in a fix for this.

For the brief period of time I was able to use build 2001051820 Win98, this bug was not fixed. The "Chrono Cross" graphic was still glitching upon shift+reload reliably at <http://ien.virtualave.net/ob/>.

The image of the weird dude at the top right hand corder of http://www.digitalblasphemy.com is corrupted with 2001052109/Linux

He looks fine with 2001052108 linux !

Well, it messed up the three times I visited the page at work. However, it renders correctly here at home with the same build (2001052109) and a newer build (2001052115). But, if I shift+reload several times (or sometimes the first time) the image messes up. I suppose this may be a different bug though... I'll test it again at work tomorrow.

I think ticmanis@coli.uni-sb.de was right. The only time I see this problem is when the transfer seems to be a little slow. I haven't seen this problem when the transfer speed is good, or from images coming from a local drive.

For some reason every time I view http://www.digitalblasphemy.com on my computer here at work, the image is corrupted. I don't know about the slow connection theory since the page loaded pretty fast and I'm getting ping times of 163 from said site. As I said before, the image loaded fine at home. Work PC: - PIII 500 - 192MB RAM - ATI Rage Pro - 19in Sun monitor - Mandrake 8.0/Enlightenment 0.16.5 Home PC: - PII 233 - 224MB RAM - STB Velocity 128 - 17in Dell monitor - Progeny 1.0/Enlightenment 0.16.5

I've seen it today with 20010522 Win32 installer build on a fast connection.

Just saw this at the target store locator on 2001052209/Linux (go to http://www.target.com and click on Store Locator under the "STORE" heading near the bottom of the page). The map that shows up after searching for a store is corrupted. BTW, the computers I listed above are on a T1 and a cable modem, respectively.

Yeah same for me. For example: http://www.target.com/common/storelocator/store_locator.jhtml?streetaddress=&city=Boston&state=MA&zip=&clientPOI2=1&closestn=3&closestprox=1&miles=200&screen=find&link=results&width=450&height=338&orig_iconid=24&_requestid=53122 This on a Linux build from this morning -- 2001052210.

I would seem that the consensus here is: please reopen this bug.

seeing on linux 2001052208, re-opening

Some comments: 0) People - including me - see this on cablemodems and T1 connections [a statement of fact] 1) Even if it happened only with slow conncections, it would still be a bug 2) This is a kind of bug anyone (even a moron^H^H^H^H^H non-technical person) will see. We may concern ourself more with things like full XML or CSS compatibility, issues we have with copy&paste, drag&drop etc. etc. that most people do not even fancy to use. But opening a Web page and seeing a corrupted image of whatever is the important thing to the average Joe is a big turn-off. Ergo: this should have a high priority as a public relation issue (or Mozilla evangelism, in a more general meaning that the one used on bug pages)

by "corrupted" you are seeing the image stretching when it shouldn't? Or are you seeing the bug where progressive gifs don't always draw correctly the first time? I'm seeing this scaling bug... but thing that perhaps a new bug should be filed on it and re-mark this one fixed. (there are a few bugs on the progressive gif thing already)

both. For example: http://hamsterrepublic.com/img/bobhitjames.gif is stretched when it shoudlnt be. http://www.westcoastaerospace.com/gif/wcalogo.gif renders with several black horizontal lines on the top edge the first time you load it However, I am pretty sure that this bug was ORIGINALY filed for horizontal white and black lines and noise in images the first time they are loaded (much worse than what appears now)

Those last two URL's both look fine to me with Linux build 2001052108.

i can reproduce both problems on windows... the original bug was due to clipping problems... the "current" bug is due to some lack-o-drawing

This doesn't have to do with clipping. The effect is always the same: some horizontal zones in images are blank, and what should be there appears in a vertically severely squashed form (above or ??) below the blank areas. Only when the missing parts are small you won't notice the second affect since it's just squashed out of existence more or less. A reliable test case should be a really large .gif on a purposefully slowed down server. The images don't have to be progressive either, just e.g. the huge gif's at http://www.irr.org/mit/BOM/1830bom-p408.html and the rest on that site. The're conventional black-and-white only, scanline-by-scanline images and get messed up really badly.

Confirmed existing in 2001052213 / Linux, with the URL I gave above.

on linux i always see this at http://www.linuxcentral.com

Linuxcentral looks like a good testcase. I saw image corruption here, but not on other pages.

Linards comments from 2001-05-22 15:30 sum up the problem pretty good (I can confirm on Linux RH 6.2, cvs build 05-25). I can provide attachments that demonstrate the scaling (in contrast to clipping), if anyone so desires. I also found that in case you have such a corrupted drawn image and loads a different page per bookmark, the image is also redrawn correctly until the new page starts displaying. I found this odd: having a repaint of the page if you want to load a different page anyway. (BTW, the blank area is alway dark blue in my case, never black)

I am seeing the black lines when I load the images of Boondocks at http://www2.uclick.com/client/wpc/bo/ in Mac 2001052408 build. All/All.

Here's an interesting tidbit... If I drag another window over the affected image, it will fix the black line problem in the area where it was covered by the window. This is particularly visible if you drag Winamp over the glitched graphic. If we could activate a window refresh of some sort (refresh as in redraw, not refresh as in reload, the way IE interprets it...), right after the page finished loading, that could fix the problem (although the black lines would still be visible while the page is loading, so it wouldn't be a COMPLETE fix).

skewer: if every image would be redrawn, Mozilla would get much slower. The only acceptable solution is to draw the image correctly the first time.

Seems like it could be dependant on ceonnection speed. I am using a cable modem (512K) which might explain why I didn't see some corruptions that others reported.

I don't think so. I see problems with my 768k SDSL at home, and also at work with multiple 45mbit links. Doesn't seem to depend on the speed of the remote site, either.

Speed definitely doesn't matter; I'm seeing this on my cablemodem. Sometimes it's just thick black bars through the image that are fixed on a click/redraw; other times, it's a series of 1-pixel-wide black bars, only with very small images. I'm using an ATI All-In-Wonder; I understand there's an imglib error only related to ATI Rage cards? Could someone update the keyword to mozilla0.9.1? 0.9 was a while ago:)

Mark B.: It's not ATI only, I get it on my NVidia Riva 128. Oh and the Target milestone is correctly set, only the keyword is wrong.

Right, but the keyword field should be consistent with target. Changing the keywords...

I'm seeing this on a Voodoo3 3000 AGP @ 800x600x16/32bppx100hz. Doesn't seem to depend on hardware. Build: 2001052720 Win98

If it can't be done for 0.9.1, we might correct the keywords as well. Please?

Changing the keywords again :-(

The problem lies in the minimal update logic in the gif decoder. It only tracks the last flushed row and doesn't notice that the current row has wrapped around, so the appropriate rectangles aren't updated. The attached patch adds logic to handle the interlace wrapping. There is still the problem that the row repeat count is ignored in HaveDecodedRow, but that's another bug (#?).

Taking bug, sticking on 0.9.1 radar.

r=pavlov

r=saari, thanks for jumping on this tor!

The two |switch| statements look an awful lot alike. If there is no salient difference between the two (I looked at them only cursorily), I'd suggest making a function (inline, if you're worried about call overhead). Other than that, sr=waterson (I'm not at all familiar with the image decoders, so I'll trust pav & saari looked at this carefully...)

r=pavlov on the latest patch

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

a=blizzard received in mail. Checked in.

Thanks tor! Can't reproduce the problem with GIFs anymore, so it seems fixed. However, with JPGs I still see the same problem, but as this summary only refers to GIFs that would be different bug. Does anyone know which one? I found several JPG-related bugs, but none that appears to have the same symptoms as this one ..

I just thought -- do progressive JPEGs and interlaced PNGs have the wraparound problem?

Hmmm.. I hate it when someone beats me to a thought... :-)

If there is not a bug for jpegs and it cannot be part of this one then who is going to submit one? I have been following this for a couple of days having just started dinking with redhat 7.1 and encountering this bug. Frankly I did not notice that this bug was gif only until the last comment. An additional data point: I found this by testing our software that runs a non interactive display that scrolls through a list of html files local to the machine so all are read from the harddrive. After tuning the disk access with hdparm and recompiling the kernel (I forgot to include dma mode support and support for the via chipset) I do not see this anymore. No mozilla changes. If there is something I can test on this platform K6-2 300MHz using XFS filesystem let me know. I am new to mozilla but would like to help anyway I can. BTW image loading ingeneral is very slow compared to netscape 4.x but I suspect that belongs in another bug :) Bret

I don't know if this applies, but there were a lot of patches to disable the eager paint behavoir possibly in an attempt to cover for this bug (my speculation: which is, most likely, flawed)... I would be curious that if that fast paint behavoir were reenable would the corruption return (if this fixed the original problem...) My $0.02 USD... :-)

Wouldn't a spill checker be nice for bugzilla ??? :)

Which build contains this fix? I'm still seeing this in 2001053104 Win98. Just as bad as ever.

2001053104 is too early to have this fix as it was checked in at about 7:30 (both Pacific time).

Not only does this WFM in 2001060104 Win98, but it looks like this update fixes bug 76703! Would verify if I could.

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

Veryfying on Skewers comment and my own observations.

Jacek, bugs which have been resolved as FIXED must be verified on all the platforms reported against. In this case the bug needs to be verified on win32, linux and Mac since the Platform is set to ALL.

Right. Unlike the other GIF bugs this one is not Windows only. Mea culpa. Reopening in order to mark fixed again.

We need verification on the fixed staus from Linux and Mac plaftorms.

I verify that the type of corruption covered by this bug is fixed on Linux.

Marking verified per comments above and verified fixed mac build 2001060408 verified fixed w2k build 2001060409

Sorry to say, this one is alive and kicking on 0.9.1. (Linux 2001060713) See e.g. http://www.irr.org/mit/BOC/1833boc-p1.html. Or is that another bug? But it looks as always, so I think it simply was not really fixed.

Hmm, I see what you mean. This case is still bad.

I haven't seen any corruption like this on Win2K 2001060704 (win32-installer-sea-talkback.exe) (1600x1200x32) Was that image interlaced on the last test case? My loaded like a non-interlaced on a slow connection (56K) and without fault. WFM? Is there something your looking for that I'm not seeing? One issue might be that the image in question was "resized" smaller than the original... I don't know if that was a contributing factor...

I think this bug had moved past interlaced gifs for a long time before it was last closed. Well I also saw this effect on some non-resized pics in www.cnn.com however the larger the image and the slower the link, the worse the corruption, it seems. It definitely does not WFM. Maybe I'll try a nightly as well.. hold on...

Seeing it on Linux 2001060621. I've got to agree with Thomas Swan. This looks like a different bug. While black bars do appear, there is also a virtical compression going on. It now only happens on large images, while this one effects even the smallest.

Confirming on 2001060721 Linux. Someone with permission might want to just change the Summary of this bug instead of filing a new one, as it already has a lot of comments on the very effect I reported earlier this morning.

You're right, the given faulting image is non-interlaced -- I assumed it was interlaced. I don't think that this bug needs any further morphing, so I'm closing it again for now and recommend that another bug is filed.

re-verifying as if today never happened.

I've just filed bug 84629 for the "new" (actually not so new) problem.

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

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