Closed Bug 65921 Opened 24 years ago Closed 23 years ago

Javascript rollovers make images dissappear.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: bteague, Assigned: joki)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; m18) Gecko/20010116
BuildID:    2001011608

Observed at the above website and nowhere else:
If you run your mouse over the main menu at moderate speed the images will begin
to dissappear, replaced by the link's alternate text.

Reproducible: Always
Steps to Reproduce:
Visit the above website.  On the main menu ("What is WINE?", "How do I get it?",
etc.), run your mouse down each slowly to verify that the rollover is working
and cache the images.  Then, run your mouse up and down the menu at a moderate
speed (enough that some of the images roll over, but not all).

Actual Results:  The images dissappear one by one (though not in order),
replaced by the links' alternate texts.

Expected Results:  Roll over the images.  Probably a little faster, too.

Find attached an HTML / JS snippet isolating the main menu.  The table has been
removed and replaced with an unsorted list to keep things in order, but the same
results were observed without the list.  The bug was ALSO observed if the links
were made static images; however, not with such ease and regularity.
one more observation:  the bug only seems to manifest itself if the images are
not in the cache.  in testing the above upload, the images somehow managed to
cache themselves; they had not done so previously.  watch your network meter
(what?? you're not running GKrellM??) and make sure that as you roll over each
image, the network activity spikes.
sounds like bug id 48020
Which I just added a link to our web page where this happens: http://www.oit.net
WORKSFORME
Platform: PC
OS: Windows 98
Mozilla Build: 2001011904

Might be a Linux only bug or a bug that was fixed recently.
Keywords: testcase
Definate dupe of bug 48020. Thanks Martin.

*** This bug has been marked as a duplicate of 48020 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified as Duplicate - 
Status: RESOLVED → VERIFIED
Brian, this is a networking cache problem. Set both cache settings to 0 in:
edit/preferences/advanched/cache and you will see that it works. If you reed
from cache to fast, then you get this kinds of result. I know your not the one
doing this, but it seems that the onmouseover event is triggered twice and
that's what might cause this bug! I had simmilar problems loading documents from
cache! If you agree please change the component to 'networking cache' and the
summary to something related and change OS to 'all' because I'm using NT4!

Bug # 48020 is about changing/missing background colors, right?
Reopening bug. I agree with H-J, this was duped against the wrong bug (48020).
Bug 48020 does contain an entry which sounds like this bug:


  ------- Additional Comments From Martin Sillence 2001-01-19 03:17 -------
  I can't see this specific site however we have a similar sounding problem 
  with http://www.oit.net Moving the mouse up and down over the blue icons on   
  the left causes them to dissapear one by one and collapse to the right.
  Linux buld 0.7 20001010517



However, bug 48020's summary only mentions background color, and that is
a separate issue. So reopening and assigning to Event Handling component.


I disagree with H-J that it is a networking cache problem, because I see 
this bug no matter what I set my cache setting to. I am always careful to 
clear the cache and restart Mozilla each time I change the cache preference.


Using Mozilla nightlies 20010116xx on WinNT and Linux. Changing OS to "All".
Status: VERIFIED → UNCONFIRMED
Component: Javascript Engine → Event Handling
OS: Linux → All
Resolution: DUPLICATE → ---
Setting default owner and QA -
Assignee: rogerl → joki
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: pschwartau → lorca
This may be a duplicate of bug 49120, "link properties not reflected until 
user interacts with the link". Reason: the mouseover properties at this site are 
all on anchor tags. And each onMousover invokes JavaScript as follows: 


        <a href="about.shtml"            
           onMouseOver="document.wine.src='images/s_wine.gif';return true;"
           onMouseOut="document.wine.src='images/u_wine.gif';return true;">
           <img src="images/u_wine.gif"
                 border=0 vspace=5 hspace=0 alt="What is Wine?" name="wine"></a>
 


However, is that it ? - because I still see the bug even after
I interact with all the links. In fact, perhaps it's a duplicate of 
bug 32269, "JS preload depends on cached image". The described behavior 
is certainly the same...


As I pointed out above, however, I see this bug no matter what my 
cache setting is.  cc'ing jst to get his opinion on whether this is
a dupe of bug 32269 - or even of bug 49120 -
Another clue to anyone who tried this bug: we are rolling over the links

                     "What is Wine?"
                     "How do I get it?"
                     "Help"

                      etc.


The bug does NOT happen every time you rollover these. It seems to be 
timing -dependent. You have to try a few times, and vary the speed 
of your mouse.


Also note: I have NOT been able to reproduce the bug with the reduced
testcase, only by going to the given URL. Perhaps this also suggests
timing-related issues.
mmm.  most strange.

i am in accord with H-J in that setting both cache sizes to '0', clearing them,
then restarting Mozilla resolves the problem.  (it also fixes the main page at
www.oit.net)  however, this seems to have the opposite effect as was
intended...the images are no longer loaded from winehq each time i roll over
them, but are actually loaded from some local source. (the network useage meter
no longer spikes.)

maybe this is exhibiting interaction with another bug...how exactly does the JS
onMouseover method interact with the cache?

(oh.  and i'm going to file the strange bulleted list problem i see periodically
on the test case as another bug.)
You are right - setting memory cache=0, disk cache=0 does make the bug 
go away. What I had tried previously was simply to try each one of the
three settings for "Compare the page in cache to the page on the network" :


                      Once per session
                      Every time I view the page
                      Never


That made no difference; I still saw the bug on each setting. Each 
time, I had memory cache=1024, disk cache=7680. But as H-J suggests, 
if I set memory cache=0, disk cache=0, the bug goes away.
I will take a second look at this site, because you both confirmed the cache
issue. I will take a look at frames and event handlers on this site, because one
other cache related bug was having troubles with that.
i don't know that frames have anything to do with it.  the testcase exhibits the
bug quite nicely for me... while it loads the images from winehq, its
organization is just an unordered list...
Cc:ing Pavlov since he's working on the new image library and also the image
cache, I believe.
Make sure to put that last testcase on your hard drive. 

First test: hover mouse over images, left to right, right to left. Don't go off
that images! Over and over again. No problem, right?

Second test: hover mouse over images, top to bottom, bottom to top. What did you
see? Ok the problem that's for sure. But watch that text inside that alert!
Pavlov, can you test if the filename is lost? I belief that sometimes the
filename is lost after the event onmouseOver. That would make it show the alt
text, right?
I'll assign this to milestone .91 and see if I can get to it.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
*** Bug 66208 has been marked as a duplicate of this bug. ***
*** Bug 66208 has been marked as a duplicate of this bug. ***
Adding myself to CC
PS. Sorry for two dup messages.
i think this is a dup of bug 20110 - "very slow, cpu-hogging mouseover of
javascript buttons"

maybe not apparent by the summary, but it addresses the disappearing of images
and re-fetching/checking of images. bug 66208 should be marked as duplicate of
bug 20110 too.
from bug 20110:

------- Additional Comments From Jeffrey Baker 2000-11-09 17:29 -------

This is re-fux0red on Linux 2000-11-09-08 Trunk and 2000-11-09-09 MN6.  To
reproduce:

1) load http://xml.apache.org/
2) Hit the reload button
3) Move the mouse around on the left-hand navigation bar.

Result: an If-Modified-Since request is generated for each event handler, and
some images change from being present, to being not found and represented by
their ALT text.

Expected result: images loaded from image cache.

This is a serious regression.  Can't ship with a browser that hammers innocent
sites.
Well the term network cache seems to be a bit misleading, I should be using the
therm image cache I guess. BTW I have a testcase on my own Apache web server,
and there I don't have this problem, untill I press the reload button.
*** Bug 66741 has been marked as a duplicate of this bug. ***
The use of document.imagename.src= is missing height and width for those images,
so now Mozilla has, well actually imglib, the job to calculate the width and
height for those images.

If things go wrong, then there's that call to StreamAbort. This will abort the
image load, or tell something did go wrong, and the result is an replaced image
with the alt text. And so, the next time Mozilla need to send an HTTP GET
request in order to receive the image. And the proces start from start again. If
this go wrong.... you know what!

And that this, take a moment for event bubbling in this example! Some rollovers,
50 images later, there are more then 7500 events triggered! This will also cause
some pain I guess! 

Note: if I put an event.stopPropagation(); before that document.name.src= stuff,
things are going better on my own Apache server, and this with exactly the same
document!
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
still looks like a dupe of 32269, unless I am mistaken. Except that that bug is
kinda dead, and this one seems to be assigned...
Yep, seems like it...
32269 seems reopened now, adding self to CC list.
Also reproducable at http://www.windough.com/howtoplay.cfm?
MID=3278452&pass=password

[URL Variables necessary to avoid login, default player's test account]
*** Bug 68969 has been marked as a duplicate of this bug. ***
*** Bug 70912 has been marked as a duplicate of this bug. ***
This seems to be working for me on Linux, debug build from yesterday. Did this
go away with the new imagelib & cache?
Re: Build 2001032804
OS: Win98SE

Disappearing image bug appears to be resolved. Some other quirks (ugly black 
placeholders during mouseover loading and some intermittent corrupted images if 
you reload) but I can't get them to disappear anymore.. 
I just marked 32269 fixed, as libpr0n has fixed all the issues i saw.  either
mark this fixed or perhaps a dupe...

for the ugly black lines, that is anther bug (assigned to pavlov@netscape).
I think this one has pretty much been cleared up.  I can no longer reproduce the
problem.  I am still, however, seeing bug 20110, "very slow, cpu-hogging
mouseover of javascript buttons" both at www.winehq.com and xml.apache.org.  The
problem is not speed in processing, it's the fact that the images are not being
cached.  I'll see if I can get the summary changed for 20110; if not, I'll open
a new bug.  However, the issue of images disappearing seems to be resolved.

Thanks!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
*** Bug 81319 has been marked as a duplicate of this bug. ***
verified the fix in win2000 Build ID: 2001-06-07-13-0.9.1
The bug seems to be fixed.
checked all the following urls:
http://www.winehq.com
http://www.oit.net
http://xml.apache.org/
http://www.windough.com/howtoplay.cfm?MID=3278452&pass=password

marking bug as verified.
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: