32269 - js preload depends on cached image

Status: VERIFIED FIXED

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

Description

[Doron Rosenberg (IBM)]

On netscapecard.com, the lower 2 images of blue balls, if you mosueover a few
times, the alt text gets shown.

2000031708 Win32 Build (Newest nightly)

Comment 1

[rogerl (gone)]

verified with 3/21 debug build

Comment 2

[John Morrison]

... -> layout

Comment 3

[John Morrison]

Actually, I seem to recall that this is a known DOM bug with loading image.src
onmouseover. Prashant?

Comment 4

[John Morrison]

worksforme with linux/win95 2000042512 builds

Comment 5

[Prashant Desale]

I saw this problem on 2000-04-21-09 with win-95, but looks like it magically got 
fixed. Today I tested it with Linux[2000-04-26-09] as well as 
Win-95 [2000-04-26-11] and now it works fine.

Marking verified.

Comment 6

[Phil Schwartau]

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

Comment 7

[Doron Rosenberg (IBM)]

20006208 win98 Mozilla build, this seems to be back. Fooling around with the
mosueover images causes the two lower ones to show alt text.  I mouseover the
top one first, then move downwards. It does not happen all the time, but sometimes.

reopening

Comment 8

[vidur (gone)]

Well...this isn't a layout bug. The stream for the image seems to be getting 
aborted (put a break on 
http://lxr.mozilla.org/seamonkey/source/modules/libimg/src/if.cpp#1637 to see 
this). As a result, we're displaying the alt text for the broken image.

I can't seem to track down why we're aborting. I'm passing it on to pnunn for 
investigation and cc:ing gagan, since the abort status is coming from Necko.

Comment 9

[pnunn]

I'm not seeing the problem on NT. Can anyone confirm the
problem still exists on win98?
-P

Comment 10

[John Morrison]

With 070508 on win95, when I mouseover the two blue (green) balls in the 
lower left region of the page, they disappear and are replaced by the ALT
text. (Okay, not win98, but close enough, no?).

Comment 11

[Doron Rosenberg (IBM)]

seeing on win98 2000071008 after profile kill.

another url is http://www.communitech.net. the top menu has various mouseovers,
but only mouseing over "Order" causes the alt text to show

Comment 12

[pnunn]

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

Comment 13

[Doron Rosenberg (IBM)]

small notice - this is a animated gif, perhaps a known bug?

Comment 14

[Dylan Schiemann]

I'm seeing this in many of the recent builds on Windoze2K.  An example is 
http://www.aacpdm.org/home.html submenu images on lower left.  I also believe 
that this bug and 46972 are related, if not the same.

Comment 15

[Dylan Schiemann]

I have found that using the objectRef.setAttibute("src",imageFileSource) 
instead of objectRef.src = imageFileSource works.  I am using this as a 
workaround for now.

Comment 16

[hirata masakazu]

I have been seeing this in recent Mac builds, too.
The problem gets more serious if there is no Alt text defined, because there
would be very small area that would respond to mouseover without gif images.

Comment 17

[Doron Rosenberg (IBM)]

the problem is that this is very annoying and a major bug.  However, i doubt 
this will be resolved for rtm. Nominating nevertheless, as well for mozilla0.9.

Comment 18

[selmer (gone)]

10/16 16 MN6

This still happens in current builds on win98, but it's not consistent.  I've
gotten the alt text once on the http://www.aacpdm.org/home.html site but only
for the top button.  If you go to any of the other buttons first, then the
alternate image is already loaded and the problem does not occur.

I could not get http://www.netscapecard.com to give me alt text under any
circumstances.  I saw other wierdness though.  One time, doing the mouseover
while still loading caused the images to just never show up - no broken image,
no alt text, just blank white space.  Another time, the mouseover would only
display the first frame of the animation so the button had a static arc around
it.  Most of the time, it worked correctly and the images animated.  If it ever
worked, no amount of moving the mouse around would cause it to then fail.

I was not able to repro on http://www.communitech.net at all.

Given that this is not already fixed, it's probably minus.

Comment 19

[Doron Rosenberg (IBM)]

It has become less often, but I do see it on 2000102906 trunk mozilla linux at
http://www.communitech.net with the order button. Sometimes, but not always.

Obviously something was checked in to make this work better, but it's a ugly bug.

Comment 20

[Dylan Schiemann]

The http://www.aacpdm.org/home.html
 site works better because I modified the code... I switched JavaScript image
swaps to changing the attribute, i.e. objectRef.setAttibute("src",imageFileSource)
instead of objectRef.src = imageFileSource ... I have seen this problem at many,
many other sites.  Another site I have developed,
http://www.westcoastinternet.net/ also has problems with image rollovers on the
navigation interface (try the large circles)... but since the images are so
small, you will see a quick flash of the blank image logo
(circle/square/triangle thing) before the image loads instead of the alt text.
If I replace the 1 line of code that change the image location using
.src=imageSource with setAttribute("src",imageSource), then the problem is
fixed!  FWIW, Also, I first noticed this bug when
http://bugzilla.mozilla.org/show_bug.cgi?id=44434 was fixed and checked in,
which fixed a more serious, but seemingly related bug.

Comment 21

[Dylan Schiemann]

The US version of election.com, http://www.election.com/us/index.htm , has this
bug as well for its rolover navigation images on the left and top of their site.
 They use .src to swap images.  The bug becomes worse if you move the cursor
quickly over all the images.

Comment 22

[selmer (gone)]

rtm-, not stop ship, still no patch.

Comment 23

[pnunn]

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

Comment 24

[pnunn]

In looking at bug 58984, the same problem exists...but the
images aren't animated. So my initial evaluation of the
problem was incorrect.

The presence of the bug is determined by whether the images are in the image
cache. Though animated images are not cached, the image container
lives (holding only a single frame) in the imgcache. This appears to be
sufficient.

The problem seems to be the assumption by js that the image has been
previously loaded.

Note: this url from #58984 could be helpful testing with
non animated js mouseover images:
	http://www.usaexpress.net

-p

Comment 25

[pnunn]

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

Comment 26

[pnunn]

	Another test from bug#60469:
http://www.open.ac.uk/stripe2.html

Comment 27

[Dylan Schiemann]

Also view http://bugzilla.mozilla.org/show_bug.cgi?id=46972 for additional
related information.

Comment 28

[R.K.Aa.]

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

Comment 29

[Jesse Ruderman]

Is this also causing bug 42499?

Comment 30

[Phil Schwartau]

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

Comment 31

[pnunn]

I just tested this with NT N6 release and
NT mozilla build and it works fine.

I also check a win98 release build and it also
works.

Can mark worksforme.

Comment 32

[Doron Rosenberg (IBM)]

linux cvs pull from today, i still am seeing this.  Sometimes it works, but if i
move the mouse over the cirlces, they do disapear.  Still seeing on other sites
too..

Comment 33

[Håkan Waara]

I'm seeing this bug on build 2000122705, Windows 98, PC.

Comment 34

[Fabian Guisset]

I can reproduce this bug with build 2000122604 win32, none of the testcases
mentioned in this bug work (i.e. the bug happens in all the testcases).
Please reconsider the resolution.

Comment 35

[Dylan Schiemann]

This bug has not been fixed, and is still a problem in the 2000122920 build on
Windows 2000.  Reopening.

Comment 36

[matxdr]

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

Comment 37

[Aaron Kaluszka]

Images don't cache properly, so the browser has to ask for the image again.
Thus, the problem is worse over 56k than T3.  It used to be only a real (and
always occuring) problem with animated images, but now it affects all images, no
matter how the javascript is coded.  More examples, seem to break more readily
with fast mouseover/offs:
Static: http://www.swva.net/
Animated: http://www.classicgaming.com/tmk/tmk.shtml
Using 2001010901 Win2K but the problem occurs on all Windows and all versions ie: N6

Comment 38

[Dylan Schiemann]

Aaron, in your comment, "no matter how the javascript is coded", does this 
include using the dom method setAttribute("src",imageRef) or only for using 
the .src?  I have had 100% success using setAttribute as a workaround.

Comment 39

[Aaron Kaluszka]

Dylan:
Do you actually have to generate the object with Javascript (createElement)
before you can use your method properly?  Can you give a simplified case with a
single image and rollover?  I think if you use a DOM generated object, there
won't be a problem (like my popup info box on swva.net) but with an HTML defined
object modified by DOM commands there might be.

Comment 40

[Dylan Schiemann]

In the testcase to follow, I was able to break the second image rollover which 
uses .src, but not the first which uses setAttribute.  Note that when I used 
the event handlers at the bottom (which are commented out) rather than the html 
attribute event handlers, I was unable to break either rollover...

Comment 41

[Dylan Schiemann]

Attachment: testcase, .src versus setAttribute

Comment 42

[Dylan Schiemann]

Attachment: testcase, slight variation

Comment 43

[Aaron Kaluszka]

You are correct, I can't break it using those methods.
Also, it looks like every time you mouseover/out, the image is re-requested by
the browser, instead of continuing to load even when its not currently displayed
like previous versions.  You can see this by watching the load meter.  This
means if you rollover repeatedly, and the images do not have time to load and/or
do not cache, they will be requested over and over, which causes the images to
disappear until all requests are done and causes the browser to slow down.  For
the old way of doing rollovers, for some reason these repeated requests are
eventually (or immediately) stopped which breaks the images.  Either way, images
should not be rerequested in this fashion, and should be cached.

Comment 44

[hirata masakazu]

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

Comment 45

[Scott Gifford (old account)]

Here's another example (from bug #65384):

   http://www.vmware.com/download/

, in the images at the top.

I don't see this when the images are in the cache, but I can get it to break
again with a shift-reload.

Comment 46

[bht237]

I have done some tests using the different methods as suggested by Dylan
Schiemann but they still break in both Netscape 6 and build 2001011804.
The error reproduces quite easily when the test is run from a local web server.
This indicates that network speed is not so much of an issue.

However I discovered something else:

If the mouseover images are centered in individual adjacent table cells that are
wider than the images then it becomes obvious that the mouseover and mouseout
events fire at the borders between table cells and not at the borders of the
images. This might be worth a separate bug record but I start it off here
because it could be the cause of this problem.

Comment 47

[HJ]

Testcase for you to confirm that this bug is related to bug 20110, or even a
duplicate.

1 - clean cache in preferences (make sure cache is enabled)
2 - run any testcase or visit the site where you can trigger the bug quickly
If it goes wrong, take a look in about:cache, do you now see images with flag
set to: PARTIAL?

If so, this bug is a duplicate of bug 20110.
Most friendly, HJ.

Comment 48

[HJ]

Or bugnumber 29370?

Comment 49

[Scott Gifford (old account)]

On  http://www.vmware.com/download/, I see:

	           URL: http://www.vmware.com/img/nav_products_roll.gif
	Content Length: 0
	 # of accesses: 53
	 Last Modified: Tue 28 Nov 2000 07:03:31 PM EST
	       Expires: No expiration date sent
	         Flags: PARTIAL

for the image that won't load.

But both bug 20110 and bug 29370 look just a little different than this bug,
have long and difficult histories, and have been around a long time.

I'd rather use dependencies to indicate that a fix for one of those will fix
this, to avoid needing an absurdly complex subject for one of the other bugs, to
encompass all of the things they already do, plus this issue; and to avoid
making people new to this bug wade through a full year of history before they
get to this issue.

Comment 50

[HJ]

Scott you are right, that wasn't very clear but all seems related in a way!

The fact that you see that flag: PARTIAL is interesting. This might be caused by
a call to AbortStream() and that might be caused by the fact that Mozilla has to
calculate the width and height's for those images. After that it has to reload
the missing image with an HTTP GET request, and the pain starts over and over
again. And thus the next image is likely to get Aborted also, because Mozilla is
then missing the CPU power, because it's image load.

Comment 51

[HJ]

M18 seem to be very odd isn't it?

Comment 52

[Kees Cook]

This bug and bug 20110 seem quite similar.  However, I thik I'll attach my test
case here, as it seems closest related.  Still reproducable in release 0.8.

This is a reduction of some web content inside www.webley.net.  I took out
the style sheets, tables, and other stuff, leaving only their images and 
the javascript.  Again, if you move your mouse over the images rapidly, there
are two failure modes:
  1) image is replaced with ALT tag text
  2) image disappears & NONE of the images will roll anymore

Comment 53

[Kees Cook]

Attachment: rapid mouseover will kill images (may require reload)

Comment 54

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 55

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is working for me on Linux, yesterday's build. I am seeing a lot of
improvement with JS and images after the new imagelib and cache landed. Could
you retest this with a recent build?

Comment 56

[Dylan Schiemann]

It seems to be fixed in 0.8.1 on Win2k.  The last testcase takes a bit to load
the images, but seems to work fine, even upon multiple reloads which caused
problems previously.

Comment 57

[Scott Gifford (old account)]

Looks a lot better on 2001032614.

I can't make the images die anymore, but I noticed some new strange behavior
instead.  It seems that if I move the mouse quickly on and off something that
requires an image reload on mouseover before the page is finished, portions of
the page that haven't yet loaded will never load, and if I later relax and hover
the mouse above something that should change, it won't change.  A reload seems
to fix these issues.

Also, I can sometimes get the images to disappear for 1-5 seconds by moving the
mouse across them quickly.

These are all from the VMWare download page (URL is above).

Comment 58

[Doron Rosenberg (IBM)]

I can't repro it anymore on any site, looks like libpr0n got rid of this for
good.  Marking this fixed.

Scott: file a new bug is the best course.

Comment 59

[Håkan Waara]

doron: don't mark bugs fixed if you don't know the patch/checkin it was fixed
by. It's used, for example, when tracking down regressions..

Comment 60

[hirata masakazu]

reopening.
This is still happening in 2001041704 Mac trunk build.

Comment 61

[Stuart Parmenter]

moving to 0.9.1

Comment 62

[Doron Rosenberg (IBM)]

[e-mail] : which site has this problem for you?

Comment 63

[hirata masakazu]

The test case of 2-28 is clearly showing this bug in 041704 build.
It did not in one of last week's build.

Comment 64

[HJ]

This is not fixed but got even worse in build 2001041704 for me on WinNT4

Comment 65

[Doron Rosenberg (IBM)]

ok, i can see this as well on newer builds, this regressed.

Comment 66

[René Bärecke]

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

Comment 67

[Doron Rosenberg (IBM)]

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

Comment 68

[Doron Rosenberg (IBM)]

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

Comment 69

[hirata masakazu]

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

Comment 70

[hirata masakazu]

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

Comment 71

[hirata masakazu]

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

Comment 72

[Doron Rosenberg (IBM)]

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

Comment 73

[Ferdinand]

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

Comment 74

[Koike Kazuhiko]

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

Comment 75

[Jens-Uwe]

mostfreq?
another fine example is IMHO www.winehq.com

Comment 76

[Ferdinand]

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

Comment 77

[timeless]

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

Comment 78

[Christoph Singer]

The problem still exists in 0.9 on Windows 2000
On pages that use Rollover images, the alt text is displayed when moving the
mouse to an image that is not completely loaded yet.
The alt text remains even when the image is most likely loaded (or does the
loading of the image break?) until the page is reloaded.
I noticed the problem on almost all pages using rollover images, e.g.
http://www.schlund.de

Comment 79

[Ferdinand]

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

Comment 80

[Ferdinand]

12 dups in 1 month: adding mostfreq keyword

Comment 81

[Dave]

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

Comment 82

[Michael Schwendt]

Same here: http://remix64.phatsites.de/

Comment 83

[Stuart Parmenter]

So the problem is caused by mousing over and image (which kicks off an image 
load), and then mousing off the image before the image load is finished (which 
kicks off an image load back for the original image)...

now this by itself is fine... but since it fails to load the mouseover image, I 
call CantRenderReplacedElement on the nsImageFrame...  which fires some 
event... now, another image load gets kicked off immediatly after the 
CantRenderReplacedElement... so basically, I need a *Can*RenderReplacedElement, 
or I (think I) can put some hacks in there to avoid this case.

Comment 84

[Stuart Parmenter]

Attachment: don't call CantRenderReplaced if we are canceling and about to load a new image

Comment 85

[Stuart Parmenter]

need r= and sr=

Comment 86

[Stuart Parmenter]

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

Comment 87

[Brian Ryner (not reading)]

r=bryner

Comment 88

[Stuart Parmenter]

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

Comment 89

[Stuart Parmenter]

fix checked in.

Comment 90

[Scott Collins]

I reviewed this with Pav before he checked it in.  I told him I'd put my sr in
the bug, so here it is: sr=scc.

Comment 91

[Stuart Parmenter]

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

Comment 92

[TommyBee (No E-mail)]

I'm still seeing this on Mac OS 9.1 build 200102115 on http://www.amygrant.com/
with the images at the top -- at least on the first load.  Subsequent loads view
fine.

Comment 93

[Dave]

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

Comment 94

[doctor__j]

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

Comment 95

[TommyBee (No E-mail)]

My comment should have been attributed to build 2001052115 (forgot a five
there).  At any rate the problem has gone away as of build 2001053108 on Mac OS
9.1.  Graphic display seems to be improved overall as well.

Comment 96

[Prashant Desale]

Verified with 2001-06-05-11.

Comment 97

[R.K.Aa.]

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

Comment 98

[Chris Hiner]

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

Comment 99

[Aaron Kaluszka]

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