Closed Bug 41624 Opened 24 years ago Closed 24 years ago

Images can't be fetched

Categories

(Core :: Graphics: ImageLib, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 41107

People

(Reporter: pierre, Assigned: pnunn)

References

()

Details

Attachments

(1 file)

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).
Attached file reduced testcase
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.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Reassigning to pnunn. When we are doing the mouseovers we are not entering the 
cache code. 
Assignee: gordon → pnunn
Component: Networking: Cache → ImageLib
Status: NEW → ASSIGNED
Target Milestone: --- → M17
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 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: