Tested with 2000-06-02 build on the Mac. I'll check on Windows after filing this bug. Steps to reproduce: 0- Go to http://www.women.com/sex/dating/svmen/ and verify that you are *not* one of the "Silicon Valley's most eligible bachelors" :-( 1- Edit the URL field to go to http://www.women.com/sex/ 2- Mouse over the link on the left (Web Sites, Toys, Quizzes) ==> Reflows occur. Mozilla displays the image name instead of the image itself, meaning that the image could not be fetched. I reduced the page to a simple testcase. The problem cannot be reproduced as systematically as on the Web site but it's still fairly easy to see it. Assigned to Networking:Cache (just a guess).

Reproduced on (VirtualPC) Win98 too: marking Platform=All. There may be a race condition somewhere. Still with a large degree of uncertainty, it feels like it's more likely to work if you reload the page and quickly move the mouse cursor and manage to stop it right on top of a link (otherwise, you can see the bug). The idea would be that if you cause a MouseOut event while it's still loading the MouseOver image for the first time, then the MouseOver image is interrupted, it stays broken in the cache and it can no longer be fetched. Disclaimer: I don't know anything to the Cache, I may be completely off.

Reassigning to pnunn. When we are doing the mouseovers we are not entering the cache code.

Notes: the images in question are www.women.com/sex/gifs/matchplain.gif www.women.com/sex/gifs/matchAni.gif and both are viewing if their url is accessed. Perhaps the base tag isn't setting up a reachable address??? -p

It cannot be a problem with the base tag: the attached testcase uses fully qualified URLs. Besides sometimes it works, sometimes it doesn't. If it works the first time, it (almost always) works thereafter and if it doesn't work the first time, it will *never* work. Thus my hypothesis of something that was stored in the cache in a broken form (see my comments when I opened the bug). Gordon says it isn't the networking cache so it must be somewhere else but it probably still has something to do with a caching of some sort.

A good place to start would be to try it after disabling the cache (I recommend turning it off in the code: I've had bad luck lately turning Networking features off by using the prefs in the Debug panel).

I noticed that once I had the image in the image cache, by specifying a view-image, when I went back to the page, the page displayed correctly. I'll dig into it. Thanks for the extra info. -p

(Why did I mention Gordon, it was Neeti who looked into it...) Another hypothesis, which includes the fact that the cache isn't hit would be the following... On mouseover, we start loading an image into an element. The mouse moves, causing a second image to load into the same element. The first image is interrupted and as a result, it is not loaded into the cache because it is incomplete... The problem is that the History (or another caching mechanism) indicates that this URL was hit in this session and is supposed to be accessible in the cache. The mouse moves again, we try to fetch the first image again. The History says it is in the cache but the cache doesn't have it. It fails. Please keep in mind that I don't know anything to Necko, the Cache, image loading or any other network-related issue. These are just random guesses.

note to self: simple test page: http://jazz/users/pnunn/publish/women.html -p

This may be a dup of bug 40767. Neeti, are you sure we don't enter the Cache code at all? See the explanations from [kin@netscape.com 2000-07-08 01:44] in bug 40767.

This is a dupe of #41107. Animated images are not kept in the image cache. They are retrieved from the necko cache and redecoded. I'm guessing that js assumes all preloaded images are in the image cache. *** This bug has been marked as a duplicate of 41107 ***

Verified dupe.