30578 - onmouseout not firing when leaving frame

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Kevin Berkheiser]

The onmouseover effects on the "about" "sites" and "help" menu items in the 
top.html frame eventually stick at one color after you move over the three items 
several times.

M14 Talkback build.

Comment 1

[Richard Zach]

I'm not seeing this on Linux build 2000.03.09.13.  Can you check with a recent
build?

Comment 2

[Richard Zach]

Ok, I think I know what's going on.  When you mouse over one of the links and
then move the mouse down, the mouseover effect sticks.  The reason seems to be
that the mousout event never fires, because when you leave the table cell that
has the onmosueover handler, you're already in a different frame.  Changing
summary, giving to HTML Frames.

Comment 3

[Ted Ashton]

Attachment: testcase

Comment 4

[Ted Ashton]

I've confirmed the problem under WinNT 4.0 Service pack 4, M14 and created a

testcase (I can't change the "Status Whiteboard" field, so someone else will
have to mark it [TESTCASE]).  I'm not convinced that "onmouseout not firing"
(which I think is what
 the above is supposed to be) is the problem.  I don't
know JavaScript, so I may
 be sticking my foot in my mouth, but I think that the
abton picture is getting
 into both array positions and so onmouseover and
onmouseout from that point
 onward are just putting the same picture up.  It's
possible that a smaller
 testcase could be created by paring down the
JavaScript, but I'm leary of trying
 it with my lack of knowledge.



By the by, this is *not* a frames problem--the testcase doesn't use frames :-)


Also, in looking for JavaScript bugs, I ran the testcase through Opera, IE5 and
Netscape 4.7 and they all worked as expected.

Comment 5

[Richard Zach]

I played with the testcase for a few minutes and could not get the image to
stick.  This is also what I observed when I opened the top frame of the original
page in its own window.  If I understand you correctly, what you're seeing is
that at some point, the image "sticks" no matter what you do.  That I don't see,
however.  By mousing over the image and then moving the cursor to the right, I
can always get the "inactive" picture to redisplay.

Comment 6

[Ted Ashton]

I think you've understood correctly what happens.  The word "help" turns white 
and stays white from then on out.  I'm not sure what causes it--it appears to be 
a timing problem of some kind.  Sometimes it will do it right off, sometimes it 
takes 20 passes.  For a while, I could be pretty much guaranteed of it if I left 
the image downward (in the testcase as well as the original page, so it wasn't a 
frames thing).  It doesn't appear to be related to how fast one enters or leaves 
or reenters the box, either.  In fact, when it was dependably showing up, it was 
always, so far as I can remember, on a clean exit, not on a quick exit-reentry 
sequence.  Of course, it could've been on the previous exit and reentry, as one 
would not notice it until the following exit.

Comment 7

[Richard Zach]

Ok, then we have two bugs here.  One I can reproduce: if an image with an
onmouseout handler overlaps a frame border, and the cursor moves away from the
image into another frame, the onmouseout event never fires.  This is what I can
reproduce on the page pointed to by [e-mail]:

1. Go to http://www.zeldman.com/about/aboutf.html
2. Mouse over one of the links in the upper right corner (say, the "sites" link)
and see image change to white
3. Move mouse downward into the central frame

Actual result: image stays white
Expected result: image should change back to grey text

The image will change back to grey if you mouseover and then move the cursor
away from the image sideways, in the same frame.

[e-mail] sees a different bug, where in some circumstances, the image
never changes back. I haven't seen that.  [e-mail], have you?

Anyways, that would be another bug.  ashted, can you figure out what makes it
happen?  maybe provide a set of steps to reproduce it?  and file it in a
separate bug?

Comment 8

[Ted Ashton]

Moving in from the sidebar or the menubar seems to be involved in it happening.
I've created bug 31788 with a slightly different testcase--one which shows that
onmouseout is continuing to get called.

Comment 9

[Richard Zach]

I see a similar thing happening when moving from the testcase image to the
sidebar, but here, like in the case of moving the mouse to a different frame, I
see no mousout firing.  CC: joki

Comment 10

[Ted Ashton]

I think I'm seeing the same thing you are, and if so, 31788 is a different bug
because the mouseout does fire even on the first failure, I think that in the
31788 bug, the failure is that

theObj = eval(MM_swapImage.arguments[(navigator.appName == 'Netscape')?i:i+1])

returns null sometimes when it oughtn't.

Comment 11

[Simon Lucy]

The string "Netscape" for appName is defined on the stack in 
NavigatorImpl::GetAppName it should be a static string.  Its possible that a 
pointer fault elsewhere could break this.

I'm still seeing this general rollover problem at a variety of rates depending 
on the speed of the machine.  On a 400MHz K6 3D on Windows 2000 it happens less 
frequently than on a 333 running 98.  Its seems more likely to happen running 
over the border of a frame into a table element than running along the row of 
table elements, but it still happens in the latter cases, especially at the 
beginning and end of the rows. Running back and forth on a row of table 
elements with 'on' and 'off' images will eventually have them all stick to 
the 'on' image.  Because they rarely if ever revert back to the correct 
behaviour its unlikely to be an event handler problem unless its become tied to 
the actual table element somehow, rather the overwriting of the image in the 
table array or the confusion of the indexes of the table seems more likely.  
This, btw, is with the current BETA branch as well as open source mozilla, as 
of this morning (21/3/2000)

Comment 12

[Jesse Ruderman]

This has to be related to bug 28858.  Would fixing that bug not fix this one?

Comment 13

[Eric Pollmann]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 14

[Kevin Berkheiser]

This seems to be fixed.  M14 was a long time ago, not really surprising.

Comment 15

[Chris Petersen]

Verified fixed in the 2001010408 build.