103558 - onMouseOver graphics downloaded every time even with once-per-session cache setting

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Steve Snyder]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914
BuildID:    2001091423

A set of buttons (JPG files) is replaced by darker graphics to indicate
highlighting.  These darker graphics are not cached in Mozilla, not are in
Netscape v4.77.

Reproducible: Always
Steps to Reproduce:
1. Go to URL and see the index on left side of page.
2. Run mouse pointer across vertical list of button and view each button being
highlighted when the pointer is placed over it. 
3. Alternately highlight/dehighlight 2 buttons and note that the highlighing
graphic is requested from the network each time the mouse pointer is placed over it.

Actual Results:  The graphic for the highlighted button is requested from the
server each time the mouse pointer is placed over it.

Expected Results:  Mozilla should cached the JPG button graphics and read them
from the cache as needed.

1. In my Mozilla configuration I have the cache "Automatically" compare the
requested object to the cached copy.

2. I do not have Mozilla configured to use a proxy server.

Comment 1

[Jacek Piskozub]

This has been fixed by the check-in to bug 92248. Tested with a fresh CVS build
(timed 2001100710)

Try using a 10/06 or fresher build. Marking as a dup of 92248.

*** This bug has been marked as a duplicate of 92248 ***

Comment 2

[Steve Snyder]

I hope you're right that this is a duplicate bug as indicated above.  I doubt
it, though.  My complaint is not about the appearance/behavior of the referenced
URL (as reported by others), but about the unneeded network traffic caused by
Mozilla's failure to cache those graphics.  If the repeated retrieval of these
graphics is causing display problems, they are not seen in my environment.  I
will leave this bug with a status of "RESOLVED DUPLICATE", but I suspect I will
be reopening it after testing the upcoming Mozilla 0.9.5 release.

Comment 3

[Jacek Piskozub]

Steve, point for you. I've just checked the net trafic with windump (a sniffer).
The "dark" onMouseOver pictures are cached with the new builds. The probem is
they are cached every time they are invoked even with "Once per session"
cachesetting.

However, I still think this is a dup. I'll look for the onMouseOver non cached bug.

BTW, why can't you install a nighty build?

Comment 4

[Jacek Piskozub]

I did the research. It seems this problem was mentioned on some others bug
pages, notaby at the end of the original comment in bug 72412 and on 2000-08-05
(yes!) on bug 20110. But it never got its own bug. It deserves one, so I reopen
it changing the summary to be more appropriate (as the graphics are now actually
cached too often).

Comment 5

[Jacek Piskozub]

Confirming with CVS 20011007 build on WindowsME

Changing OS/Platform to All/All

Comment 6

[Steve Snyder]

Jacek, in reference to your comments of 16:54:

>just checked the net trafic with windump (a sniffer)

I saw the behavior in the logs of the Squid proxy (configured as transparent, so
Mozilla isn't aware that I am using a proxy server).  Any means to view the HTTP
requests made by Mozilla should do the job.

>they are cached every time they are invoked

I may have expressed myself badly when I asserted that the graphics are not
cached.  I ASSumed failure to cache because I can see that the specified objects
are requested on each MouseOver.  What I should have said is that the requested
files are obviously not being *read from* the cache.
>BTW, why can't you install a nighty build?

I can, but I usually just install the lastest releases.  Done to avoid those
dumb what-was-I-thinking-when-I-wrote-that bugs that are usually fixed the next day.

Comment 7

[Anatoly Kochergin]

BTW, described behaviour (buttons highlighting) doesn't working at all in IE6.

Comment 8

[gordon]

Pav, it this a problem with ImgLib or do you think it might be HTTP?

Comment 9

[gordon]

Once more, with feeling:  Pav, do you think this is an ImgLib problem, or could
it be HTTP?

Comment 10

[basic]

This seems to works for me on build 2001101909 win32
I think it is a dup of bug 92248

Comment 11

[basic]

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

Comment 12

[basic]

ok, maybe I'm not seeing the bug as well because the images are small

http://www.uspto.gov/

has bigger images

Comment 13

[Jim Avera]

This (repeated downloading) is definately the problem.  
I have a DSL modem and I can see the activity light go whenever
I move the mouse over the items on  http://www.uspto.gov/

Comment 14

[scattol]

I have a cable modem and I don't see the chatter between http://www.uspto.gov/
and me at this time. However I do see this problem with my site
http://www.rasc.ca:22002/rasc/ (but no problem download each time with Netscape 4
or with IE5.5). The javascript doing the image swap appears
to be the same on both sites so it doesn't look like it's to blame.
Maybe it's something on the server site. An early html version of that rasc.ca
site served by apache didn't seem to cause traffic whereas the final version in
jsp served by tomcat 3.2 definitly shows the problem.
Could it be that the images aren't cached because of a difference
in the way they are being served? 

Comment 15

[scattol]

I have a cable modem and I don't see the chatter between http://www.uspto.gov/
and me at this time. However I do see this problem with my site
http://www.rasc.ca:22002/rasc/ (but no problem download each time with Netscape 4
or with IE5.5). The javascript doing the image swap appears
to be the same on both sites so it doesn't look like it's to blame.
Maybe it's something on the server site. An early html version of that rasc.ca
site served by apache didn't seem to cause traffic whereas the final version in
jsp served by tomcat 3.2 definitly shows the problem.
Could it be that the images aren't cached because of a difference
in the way they are being served? 

Comment 16

[Stuart Parmenter]

fixed