66064 - js doesn't load the new Image() images automatticly for onMouseOver

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[mar_garina]

Description:
In netscape & IE, when a browser encounters something like:
a=new Image(100,100);
a.src="path/to/image.gif";

it automatticly [down]loads the image and put it in the memory. it's usually in
use with onMouseOver/onMouseOut events, so when the mouse is over an image it'll
be replaced by another image. (Such as a pressed button effect)

In NS & IE the should-be-replaced image (Say, the pressed button image) is
already downloaded so it takes less than a second to replace it (to see the
button clicked). Mozilla, However, starts downloading the image only when the
mouse is over the image, and it takes much more time than in the other browsers,
and the pressed-button-effect is less nice.
Not only this- When the mouse will be out of the image and will come over it
again the image will still not be in the 'memory', and it'll d/l it over again.

(I also noticed that sometimes, if the image still didn't finish to be
downloaded and there's onMouseOut, it destroyes the image or something.. But I
couldn't find a way to reproduce it in 100%, so maybe I'll report on it later.)

How it should be: 
new Image() should make it download the image just the way it downloads an <IMG
SRC="">.

How to reproduce:
view the url, http://www.deot.net/jstest.html
if you want, try it with ns 4.x or ie - it's much faster.

Comment 1

[Phil Schwartau]

Browser, not engine. Not sure of the best component to handle this,
but since the idea concerns new Image(), let's start with DOM Level 0 - 

Comment 2

[HJ]

Can't confirm on build 2001011904 on WinNT4. Example works for me! Reporter what
build are you using?

Comment 3

[mar_garina]

You are right, That was not a good example.. I tried now to find out the real
reason but didn't succeed yet..
A similar thing to the bug I talked about happens when you choose 'reload' in
this page, which seems like it tells the image to NEVER be taken from cache,
even though it was loaded once (It'll keep loading it over and over when you
move your mouse over it). try it, I think that it shouldn't be that way either.

About the original one I'll try to find what causes it..

Comment 4

[Keyser Sose]

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

Comment 5

[mar_garina]

First - I also noticed bug 66521 - but it's not what I reported about.

Now I made a better job and sat down about half an hour to find the bug I was
talking about, and I've found three [different?] bugs:

1. When there's any image that should be replaced by another one in onMouseOver,
and the two images are already in the cache, if the user clicks 'reload', the
two images won't be reloaded once - every onMouseOver/Out will keep reloading them!

2. When the charset is set to 'windows-1255' (Hebrew), onMouseOver/Out will
again, reload the images over and over. I have no idea why it relates to the
charset - but with charset iso-8859-1 it didn't make this problem, for example.
I didn't check other charsets yet, So I can't conclude anything from that.
NOTE: if the images are already cached it won't work ! Please delete the cache
before testing it.

3. If the original location was something, and it forwarded the browser to
another location that contains onMouseOver/Out, even if the images are cached
they'll keep being reloaded.

How to Reproduce:
Bug 1: in any site that has onMouseOver/Out, for example:
http://www.deot.net/jstest.html

Bug 2: [Clear the cache] http://www.deot.net/jstest.html

Bug 3: http://www.deot.net/forward.html (forwards to jstest.html)

Comment 6

[Johnny Stenback (:jst)]

Image lib/cache problem, reassigning to Pavlov.

Comment 7

[HJ]

If you set both cache settings to 0 (mem/disk) then this never happens for me.
So at the end this might be just another dup or at least related to bug 65921.
The main problem for almost every image rollover bugs seems to be related to
image cache and event handling. It almost looks like an 'forced' reload
somewhere in the source.

Comment 8

[mar_garina]

It seems to be fixed with the (great) new cache.

Comment 9

[Stuart Parmenter]

new imagelib/cache fixed this.

Comment 10

[Prashant Desale]

Verified with 2001-06-05-11.