This happens consistently on my home system but not work and the same has happened to a co-worker. I have the M5 version and am running identical OS's and the systems are similar. The browser does not display the transparent gifs we use for alignment. We are very concerned as a lot of work would have to be put into making a NS5 version of our site.

Don, can you take a look at this. Or if you know who should be getting this, please reassign it. There is another bug similar to this, but I'm not sure of the number.

[QA Assigning to self, and CC:ing beppe. Dunno how this fell into Frames, given that the page doesn't use any; relocating to layout.]

Using the 5.17.99 build on Mac OS, Win32 & Linux, I'm not seeing any issues with transparent GIFs on the www.corbis.com root page; have you perhaps tried a more recent build? (FWIW, I'm also not aware of any other issues with transparent GIFs not displaying in recent builds.)

But ... I see this on win95 using 1999051708 viewer.exe. I played with a few permutations and I think the condition is (1) loading using http:// (but not file://), (2) resizing the GIF from it's "native" size, and, (3) (probably) loading via modem/"slow" connection. Transparency is not a factor (except that these tend to be the most commonly resized type of image). So that would be netlib/necko/cache ... M7? I don't have a specific bug number either, but I know this has been mentioned for bugs filed on slashdot.org (for example, bug #6639, bug #5209, or bug #5024, which all make mention (amid pointing out other stuff ;)).

Reassigning component to Networking Library, as it sounds like it's timing out on the images and displaying the alt text (per John Morrison's comments above, and the screen shots e-mailed by John.)

Okay, this is somewhat in contradiction to what I said yesterday, but there is still a specific problem with loading the same image "multiple" times from the same page. (Of course, Necko may make this all a moot point in a while; I apologize if this is redundant information). Today: (1) Testing over a broadband connection (>10Mbps) so transport speed is not a factor, and (2) resizing appears to *not* be the driver; However, loading the same image many times seems to be the problem. This is using apprunner 1999051708 and Nav4.51 on win95, each started with a deleted cache directory. The HTML test page had 20 <IMG SRC> all pointing to the same GIF on a server, but with different width/height attributes (somewhat similar to the way the the proverbial 'spacer.gif' is used on the Web to get pixel accurate layout). The GIF used in this test was not 'transparent'. On the page itself in _apprunner_, the first 5 instances of the image are displayed (at varying width/height) and the remaining 15 are NOT DISPLAYED (but their "placeholder" is) -- i.e., they fail to "load" even when they are already in the cache. All images load in _Nav 4.51_. From the server logs: Apprunner GETs (starting IP trimmed off to fit this report form): fromip - - [20/May/1999:20:11:53 -0400] "GET /ccs.gif HTTP/1.1" 200 14640 fromip - - [20/May/1999:20:11:53 -0400] "GET /ccs.gif HTTP/1.1" 200 14640 fromip - - [20/May/1999:20:11:53 -0400] "GET /ccs.gif HTTP/1.1" 200 14640 fromip - - [20/May/1999:20:11:53 -0400] "GET /ccs.gif HTTP/1.1" 200 14640 fromip - - [20/May/1999:20:11:53 -0400] "GET /ccs.gif HTTP/1.1" 304 0 fromip - - [20/May/1999:20:11:54 -0400] "GET /ccs.gif HTTP/1.1" 304 0 fromip - - [20/May/1999:20:11:54 -0400] "GET /ccs.gif HTTP/1.1" 304 0 In contrast, Nav4.5 GETs the following: fromip - - [20/May/1999:20:17:49 -0400] "GET /ccs.gif HTTP/1.0" 200 14640 fromip - - [20/May/1999:20:17:49 -0400] "GET /ccs.gif HTTP/1.0" 200 14640 fromip - - [20/May/1999:20:17:49 -0400] "GET /ccs.gif HTTP/1.0" 200 14640 fromip - - [20/May/1999:20:17:54 -0400] "GET /ccs.gif HTTP/1.0" 200 14640 So, while Nav4.5 does 4 GETs to the same URL (ok), apprunner does 7, of which the first 4 are code '200' and the next 3 are code '304'. No sign of any further GETs. [Also, Nav4.5 stores 3 copies of the image in its cache. Apprunner stores 4.] If you want the HTML I'll attach it, but it is nothing but IMG and BR. (Note that (see previous messages) this may be machine/location/phase-of-moon specific bug and _may_ not occur for all win9x boxes).

And then I thought --- what if all the images had the same dimensions? Answer: Using a page where all images have the same width/height attributes: o Nav4.5 issues ONE and only one GET; ALL images on the test page are displayed. o Apprunner issues ONE and only one GET; ALL images on the test page are displayed. So ... resizing the images _is_ a co-factor.

I think bug 6307 may be a duplicate of this bug, but defer to someone else to wield the axe, if appropriate.

I've seen no reports of this bug recently, and can't reproduce using the Corbis site using recent builds on any platform. Thus, verifying as WORKSFORME. ---> johnt@corbis, if you're still seeing this problem on a recent build, could you please insert your $.02 into this bug report? Thanks!