Closed Bug 65921 Opened 24 years ago Closed 24 years ago

Javascript rollovers make images dissappear.

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: bteague, Assigned: joki)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(2 files)

test case illustrating the bug.
1.62 KB, text/html
Details
Testcase what do you see here?
8.23 KB, text/html
Details
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 ago → 24 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: