Closed Bug 93461 Opened 19 years ago Closed 8 years ago

images swapped via JS are loaded again and again from network


(Core :: Networking: Cache, defect, major)

Not set





(Reporter: mkl_mozilla, Unassigned)




(5 keywords)


(3 files, 1 obsolete file)

using CVS build from 31/07/2001 i see following: on there are 
navigation "buttons" which are changed via java script OnMouseOver. Each time I 
move cursor over that buttons images are again and again loaded from network.
I don't understand javascript enough to know why, but should a mouse-over
actually kick off a networking event?
It looks like the JavaScript at this site is written to load the images
off the network. Here is a sample of the HTML:

   onMouseOut= "imageOff('con_1')" 


        width="9" height="8" border="0" alt=""


Now look at the functions imageOn() and imageOff(). They take a name
like "con_1" above and read the "onImg", "offImg" arrays for it 
to set the image src:

// Swap images on based on a name array
function imageOn(name) {
  if (document.images) {
    document.images[name].src = onImg[name].src

// Swap images off based on a name array
function imageOff(name) {
  if (document.images) {
    document.images[name].src = offImg[name].src
The onImg, offImg arrays store network URLs. I will attach a version
of the HTML below containing debugging alerts in the imgOn(), imgOff()
functions showing you exactly what is being set -
Load the testcase in Mozilla. Slowly mouseover the "Products & Services"
button; then slowly mouseoff it. You will see the network URLs being used
to set img.src.

I do not know enough about caching etc. to know when Mozilla is currently
using a cached version of an image it has already loaded once, or if it 
is even supposed to use such a cached image if the JavaScript is executing 
this kind of command...
calling on imagelib...
I'm seeing this on Linux with a build from yesterday.
Summary: images swaped via JS are loaded again and again from network → images swapped via JS are loaded again and again from network
4.7 loads the images at page load, and doesn't reget them on mouseover, but if
it's bad code on their part i'd prefer evangelism over 4xp.
Ever confirmed: true
Hey Pav,  do the image requests go right from Javascript to ImgLib or are they
requesting images from HTTP?
Assignee: gordon → pavlov
Does this cause the delay described in bug 92248 ?!
Keywords: mozilla0.9.6
OS: Windows 2000 → All
Hardware: PC → All
Filed new one - bug 108161
Severity: normal → major
Keywords: top100
seems to wfm with build 2001112104 win32
but after a reload with build 2001112104 win32 it slows down again (and there
may or may not be loaded from network [I'm not sure about that])
now this seems to look more like a dup of bug 108161
*** Bug 113129 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
Here is a image mouse over script that properly caches images on all 
milestones. Mozilla builds will not repeatidly reload the images from the 

Example page:

<Java Example ---

if (document.images) {
  var defImg = "home";

  var homeoff = new Image(); homeoff.src = "images/az-top-menu-2.gif";      
  var homeon = new Image(); homeon.src = "images/az-top-menu-2b.gif";

 var climateoff = new Image(); climateoff.src = "images/az-top-menu-
  var climateon = new Image(); climateon.src = "images/az-top-menu-3a.gif";
function actMenuItem(imgName) {

function inactMenuItem(imgName) {

function act(imgName) {
  if (document.images) 
    document[imgName].src = eval(imgName + "on.src");

function inact(imgName) {
  if (document.images)
    document[imgName].src = eval(imgName + "off.src");

<Page Source ---

<img border="0" src="images/az-top-menu-2b.gif" name="home" alt="Home Page" 
title="Home Page" width="61" height="23" />

<a href="climate.html" onMouseOver="actMenuItem('climate')" 
onMouseOut="inactMenuItem('climate')"><img border="0" src="images/az-top-menu-
3.gif" alt="Arizona Climate" title="Arizona Climate" name="climate" width="76" 
height="23" /></a>


It seems Milestone 0.9.7 has resolved the caching of images (at least on 
Windows XP).

Another example: this fires a 3rd 
image and works under Windows XP using milestone 0.9.7

After testing many different websites with numerous types of "onmouseover" 
and "onmouseout" events, it seems to be working great and not trying to look 
for the images on the given server(s).

Great work and keep up the continued AWESOME CSS support and implimentation.

I for one am an advid supporter of the new milestones being released; gives IE 
and Opera some good reasons to keep improving their CSS support.
Discovered something unusual; After testing Milestone 0.9.7 (Win32) and then 
opening Netscape 4.08, checking the same site(s), I found that returning to 
Mozilla 0.9.7 will then try and look for the cached images on the server 
again, even after reloading the page.

Could their be a system registry conflict somewhere?
Keywords: mozilla1.0, perf
this bug had been fixed by other patch on trunk,but i don't what it is number,so
i think this bug should be closed or dup,i test trunk,and open the url
"",when i move cursor over that buttons images didn't loaded
from network,it was seen ok!
Anto from sun browser china
WFM Mozilla 1.0 RC1, WinME. For housekeeping, this should be marked as fixed or
Well Using 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020428
I still see this.
When I pass the mouse over the images and move it out the image take about 2
sec' to return to its previous state.
Doing it several times doesn't cache the images - or at least doesn't seems so.
again - sorry for the spam but I don't see this problem any more
(same build - same everything)
see my comment 15 in bug 133217 which BTW I think is a dup of this one.
Anyway WFM now so ignore my last comment.
as part of bug 133217, i just checked in a fix for this.
Depends on: 133217
Target Milestone: Future → mozilla1.0
ignore my previous comment.  the patch doesn't seem to help
No longer depends on: 133217
I am still unable to reproduce this on 1.0 RC1 (Windows ME). Can somebody
confirm this bug a recent build please?
i can't reproduce this anymore either.
Linux 2002042708 loads the alt images at page load and not again.
bug 133217, which is similar to this one, was just solved due to a fix to bug
Reporter: can you check if you still see this.
No one seem to be able to reproduce it any more.
I think we can close this as WFM
Just checked on this bug again. has changed
There are no more navigation "buttons" or any images that change onmouseover.
again I think its time to close this one.
I agree to close this bug. I  checked it just before HP changed design of the 
page and it worked.
move mouse slowly over box and see how many times we receive 'over/out' events.

tested on: 
- Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0rc2) Gecko/20020510 
- IE 5.5SP2
- Opera 5.12/6.01
Konquror 2.2.x isn`t tested - we cann`t write on another window (not
Compare this sample to Netscape 4.7x - over and out events only when mouse
enter/leave layer and NEVER(!) when we move mouse inside layer.

I cann`t comment new browsers behaviour. We should change old js according new
browser onmouse-over/out feature.

Is this common bug or new browsers implement events correct ?
Blocks: 61480
Keywords: mozilla1.0mozilla1.1
*** Bug 152875 has been marked as a duplicate of this bug. ***
If it does help to fix this bug...

I tried to reproduce the issue from bug 152875 with newer build and it was OK.
( It was also OK on other machine with older build )
But it seems the the actual reason for that bug is image file creation time.

All image files created on server more than 24 hours ago are not requested
again, but newer files are requested every time. I did small test andd rolled
back creation date of 2 files ( while other 2 still have today's date ) and
behavior was different for these 2 pairs. Browser loaded files that have today's
date over and over again. 
So if you go and try URl from bug 152875 it will most probably will work.
stop adding ns keywords
Keywords: nsCatFood
Using Build 2002071208 on Windows 98, and also with Mozilla 1.0
I can see this behavior on 

Mousing over the buttons in the top or right menu causes Mozilla to
reload the highlighting images. Going offline before moving the cursor
over the menus shows that Mozilla has preloaded the images correctly.

If I go Back or Forward to this page then it behaves correctly, but if
I open the same page in another tab or window it goes back to fetching
the images over and over again.
Keywords: perftopperf

Mousing over the menu images on the left causes a flash of the progress meter
and the stop button. My ethernet card light blinks with every mouseover also.
*** Bug 157798 has been marked as a duplicate of this bug. ***
*** Bug 160545 has been marked as a duplicate of this bug. ***
*** Bug 160563 has been marked as a duplicate of this bug. ***
this bug also affects the standard netobjects fusion and dreamweaver image
preload scripts.
im sure this didnt happen with the frist couple version of mozilla, gonna try in
the next couple of days, i think it started around 0.9.9, but will try soon

this bug is a regression and need a new target
heres an url made with netobjects fusion:

since this bug affects all mousovers created with dreamweaver or netobjects this
is very major ! most minor sites on the web are made with these 2 editors.

adding regression keyword since im sure this didnt happen with 0.9.something
Keywords: regression
Pav, what is currently being done about that?
Keywords: nsbeta1+
Whiteboard: [adt1] [ETA Needed]
Target Milestone: mozilla1.0 → mozilla1.2beta
Attached file Javascript Image Reload with Buffering (obsolete) —
As the other attachment didn't reveal the bug to me I offer my own testcase:

The page reloads an image using a Javascript image object for buffering. 
When the image has finished loading into the buffer, the onload event fires and
the handler should display the image on the page. At this moment Mozilla asks
the server, if the image has been modified. This duplicate request is unwanted
and doesn't happen on Netscape 4.7x.

Check the HTTP GET requests using your favourite network sniffer on port 8903
or your proxy's port.
It does seem that as per comment 33 there is some sort of time delay
involved--I'm having more trouble with network fetching of newer images (kind of
untechnically tested--I unplug the network and see which ones swap on mouseover
anyway). Don't know if that's helpful or not.
Instructions to catch HTTP requests and responses using ethereal.
(see for more information)

1. Capture packets using Capture -> Start.
"Filter:" for e.g. port 8903 by entering "port 8903".
Enable "promiscuous mode" if you snoop a conversion between to remote hosts
(make sure you are connected to one of them through a hub and not a switch :-)
Press OK to start snooping.
2. After collecting enough data (300 packets should be enough) stop snooping,
decode the packets: Tools -> Decode As: On Transport Tab select "TCP" and "both"
and "HTTP" -> Press OK.
3. Now filter the HTTP headers: Press Filter (lower left corner), enter
Filter name: "HTTP", Filter string:"http.response == 1 || http.request == 1" and
press (in that order) New, Save, Apply, OK!

Now ethereal lists you only the first packet for the requests from the browser
(including the filename) and server responses.

Do we get this in for 1.2b ?
caillon, you had some thoughts on this, no?  From what I recall, fixing this
would require big risky stuff that could maybe be landed in an alpha milestone,
Keywords: helpwanted
It seems that using "Reload" activates this bug.

I've made some tests while watching server logs. If I started Mozilla with
clear cache everything went very well - every image was loaded once while
loading and then swapping was fast and generated no network traffic.

Then I've closed Mozilla and started it again. When I went to this page
again only main HTML file, which is automaticly generated and should not
be cached, was loaded.

But after reloading the page I got "hover" versions of images reloaded
twice - once when page was loaded and once more when I moved my mouse
over swapping images.

When I used Shift-Reload it was even worse - some of the images was
downloaded even 3 times - once while page was loaded and two times when
moving my mouse over images. It was strange that some of them were
downloaded 2 times and some 3.

After closing Mozilla and opening it again everything went back to normal.

I've used for testing. It uses not
standard method for preloading "hover" versions of images - not by script
(img=new Image(); img.src="...") but by CSS background-image. My own
idea :-)
A couple more examples: 

mouse over left
mouse over the icons.
Attached patch WIP patchSplinter Review
This seems to do the trick.  I've had walk84 test an earlier version of this
and verify that it works, without appearing to cause any major regressions.

I've got some polish and testing to do still, so I don't think it's quite ready
for review.  But comments could be nice.
Blocks: 178882
reassigning to myself
Assignee: pavlov → jdunn
caillon, I looked at this bug and at your patch.  While I am knew to
all this code (add to it all of the caching code as well) I was wondering
if you could explain briefly the change you are making.  It looks like
you change the "container" of images from PresContext to the Document
and I was wondering what this buys us.

Also were you able to detect what the actual problem is?
i.e. is the fact that we are using a CSS rule to load an image we 
     are somehow overriding the caching process?  

Sorry if these questions sound lame but am trying to understand exactly
what is going on.


I'd like to suggest having a look at the discussion of bug 121084,
which is also about "Images requested twice". 

Additionally bug 153633 exposes a similar behaviour and may be of interest for the 
avid patch programmer. At least it has a nice testcase. :-)

Congrats everybody!

This bug seems to have vanished automagically with release 1.2.1.

Does anybody know why it works now and what fixed it?

PS:I am running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130.

Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
added topembed
Keywords: topembed
Keywords: topembedtopembed+
This does indeed look like it is fixed.
Using NSPR_LOG_MODULES=nsHttp:5 I am seeing on the first
"GET" request for the image and subsequent requests are
gotten from cache.  If no one can reproduce this then
I plan on closing it out.
This seems to be working, anyone else see it not?
*** Bug 176259 has been marked as a duplicate of this bug. ***
I'm still seeing this in 1.3b (2003021008 WinME).

My disk cache is set to 0 (I don't know if this is relevant, but it might be).
Is your memory cache also set to 0?
No, memory cache is set to 8192.

This is what about:config says (BTW: why doesn't the Cache properties panel show
memory cache settings any more?!?):

browser.cache.check_doc_frequency: 3 (default, "When the page is out of date")
browser.cache.disk.capacity: 0       (user set)
browser.cache.disk.enable: true      (default)
browser.cache.enable: true           (default)
browser.cache.memory.capacity: 8192  (user set)
browser.cache.memory.enable: true    (default)
After fooling around without being able to reproduce it, I found out that this
happens only when the memory cache is full, i.e. when about:cache shows "Storage
in use" is more than "Maximum storage size".

I can easily make this happen on, because just
loading this (simple) page fills up my 8 MB memory cache. This is because the
site contains a 13367-byte gif image,,
which occupies 6378400 bytes in the cache (over 6 MB!) because it's 1200x1700.

So a simple way to reproduce it is:

1. Set memory cache to 8 MB, turn off disk cache (maybe?).
2. Load bugzilla in a window
3. Load in another window
4. Note that mouseovers on menu on the left are extremely slow as images are
reloaded every time.
5. Load in a third window
6. Mouseovers are still slow
7. Close window
8. Mouseover all images on
9. Mouseovers are fast again

cell_bck.gif is stored in tha cache twice, once as 13367 bytes and once as
6378400 bytes. This is what about:cache?device=memory shows:

     Data size: 6378400 Bytes
   Fetch count: 1
 Last Modified: 02/23/03 15:33:12
       Expires: 02/23/03 17:33:11

     Data size: 13367 Bytes
   Fetch count: 1
 Last Modified: 02/23/03 15:33:12
       Expires: 02/23/03 17:33:11

I think the real problem here is that the cache is storing decoded images as
well as just the file. But I suppose that's another bug? It can't be
intentional, can it?

I don't know if this happens with the disk cache enabled.
well it sounds like you're shooting yourself in the foot by only allowing 8mb of
cache. however the second entry looks like something which we should
aggressively prune instead of allowing it to fill up your cache.
Target Milestone: mozilla1.2beta → ---
cant see such a huge 6mb file in cache when viewing that page with ns4.8 ...
> It can't be intentional, can it?

It's pretty intentional....  See bug 143046 for some work to reduce the amount
of cache being used, though.

That said, 8bm is _more_ than our default memory cache setting, so if we're
using up that much cache to view images we need to up that setting....  I've
filed bug 194619 on that.

(and the UI was removed purposefuly, "because there is no really good reason for
users to be able to change it"; but then we should provide a better default).
>it sounds like you're shooting yourself in the foot by only allowing 8mb of cache

Just thought I would say in his defence, for the past 3 years I've had disk
cache set to 0 and 6 or 8M of memory cache in all of my Mozilla/Netscape/Phoenix
profiles, and performace has always appeared better without the constant disk IO

> "because there is no really good reason for users to be able to change it"

If my machine had 256M, instead of being maxxed out at a measily 128, I would
easily slide Mozilla's mem cache up to 40 or 50M. I think there are just as many
uses for a user editable mem cache as there are disk cache.

Why not use a percentage of the systems resources, for a default? User profile
drive has 30G free? Use the maximum useful disk cache size. User machine has 64M
of memory? Use only 4M mem cache... etc.

Disk cache size:
  (*) Automatically use optimum size
  ( ) Manual size: [  12] MB
> Why not use a percentage of the systems resources

That was the idea last time this was all discussed; not sure why we didn't do it.
cause its a pest, on a 1 gb ram system with 80 gig free hdd, i dont want mozilla
to use even 10% of it as cache ...
Why not, if the ram is not being used by anything else?  If it is, the memory
pressure observers will fire, reducing the size of the memory cache....

(the percent of resources argument does not apply to disk cache nearly as well
as to memory cache).

Also, the memory cache size could be pretty nonlinear wrt to the memory size. 
It's trivial to have it plateau off at some value like 50MB.....
> Why not use a percentage of the systems resources

That would be bug 105344, fwiw.
cc'ing gordon.  there's an existing bug about the cache size getting out of sync
with what is actually in use.  gordon can you check if this is a duplicate?
Keywords: topembed+topembed-
Whiteboard: [adt1] [ETA Needed]
Comment on attachment 96293 [details]
Javascript Image Reload with Buffering

Camera URL is not valid any more.
Attachment #96293 - Attachment filename: moz_ifmod.html → moz_imgswap.html
Attachment #96293 - Attachment is obsolete: true
Assignee: jdunn → nobody
QA Contact: tever → networking.cache
i can't see the problem on anymore.
is this fixed ?
can somebody provide another testcase ?
Can't repro this on
Tested with Firefox, Firebug 1.05, and WireShark 0.99.4 on Kubuntu Fawn.
this is also wfm with Seamonkey trunk
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.