21371 - Multiple mouseenters occur without mouseexit

Status: VERIFIED FIXED

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

Description

[Jerry Baker]

If you rapidly move the mouse in and out of the left frame to trigger the
mouseover event on the buttons you will notice that they frequently get "stuck"
on. I am not sure if the JavaScript is getting stuck thinking that the mouseover
state is still true, or the layout just doesn't paint properly.

Comment 1

[Mike McCabe]

Reassigning to Event Handling.

Comment 2

[rods (gone)]

I was unable to bring up the URL shown above, but this may be an image cahcing
bug, which means it would be a duplicate.

Comment 3

[Jerry Baker]

The URL works from here and successfully answers pings from two different shell
accounts, but who knows about Netscape's network connectivity. I don't think
this is a caching mechanism issue. The images do not restore themselves when the
mouse is no longer over them (onMouseOut). Also, on later builds (1999121320),
the image flips sometimes show no image and just the ALT text OnMouseOver
instead of the specified image.

Comment 4

[Michael Collette]

I also have the very same problem on my web site.

http://www.testequity.com/nav1.phtml

  The key to duplicating the problem is to have the mouse start from outside the
browser window to the mouseover object.  Although not required to replicate this
will cause the error with even slow mouse movements.
  The one thing that both my page and the one reported in this bug have in
common is that both scripts attempt to memorize the default image for the swap
back.  Pages that have scripts which explicitly assign what graphic to swap back
in on the OnMouseOut do not have this problem.  For example, another page of
mine...

http://www.novatron.com/

  This uses an older version of that mouseover script before I tweaked it to be
more clever.

  Considering the fact that Dreamweaver creates mouseover scripts along the
lines that cause this error you might consider upping the severity on this.
There's going to be a LOT of sites with this glitch.

Comment 5

[ekrock's old account (dead)]

Bulk moving old [makingtest] code to new makingtest keyword. Sorry for the spam! 

Comment 6

[Mike McCabe]

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

Comment 7

[Steven de Hoog]

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

Comment 8

[Joseph Elwell]

I was unsuccessful at making a test case. and the maxim page has changed.

Comment 9

[Kevin McCluskey (gone)]

Attachment: Simple test case

Comment 10

[Kevin McCluskey (gone)]

The problem is mozilla doesn't always report a single mouse enter and exit when 
going into an element and leaving it. Sometimes you get two mouse enters and a 
single exit. If the JavaScript code is written to assume that there will be an 
exit for every enter when moving the mouse through the element it will fail. 
Looking at the JavaScript in http://www.novatron.com/ it looks like it assumes 
it can toggle the image on each mouse enter and exit.

Here is some output for the simple testcase which shows that multiple enters are 
generated when you move the mouse pointer from outside the browser window over 
the <P> element.

enter exit
enter exit
enter exit
enter exit
enter enter exit
enter exit


The output of the simple test 

Comment 11

[Jerry Baker]

Viewers of this bug with NC 4.X will not be able to see the testcase because NC 
4.X will not fire events on elements that are not links.

As noted before, Macromedia DreamWeaver relies on the behavior that is broken in 
Mozilla for swap image restores.

Comment 12

[joki (gone)]

The testcase gets confused becuase it uses a simple toggle but the basic problem 
is that my enters/exits do not always pair up.  I'll look at it more.

Comment 13

[K Chayka]

I think I've been experiencing another case of this same kind of bizarre mouse
event behavior on Win98 build 2000030215.

I have a test page at http://www.vortxweb.net/ccs-pg/mz_index.shtml that has a
disappearing menu.  A mouseover or click on the menu button in the top left
corner of the page should show or hide the other menu buttons.  With the code
below, the mouse events only work correctly if the cursor goes over the button
coming at it from the right side.  If the cursor goes over or away from the
button from beneath or above it, the setMenu function gets called 2 or 3 times,
like it's making up its own mouseout function or something!?!  I included some
alerts in one test, so I know this to be true.

<!-- mouseover or click on the menu button changes the state -->
<div ID="menub"><a href="javascript:setMenu('mainMenu')"
onmouseover="javascript:setMenu('mainMenu')"><IMG NAME="btmenu"
SRC="./icons/bt_menuoff.gif" BORDER="0" HEIGHT="24" WIDTH="94" ALT="Display or
Close the Site Menu" VSPACE="1"></a></div>

Since there is no mouseout behavior specified, whatever happens on mouseover
should remain until another mouseover or a click on the menu button.  The really
weird thing is that if I add the ID="menub" attribute to the img tag, it works
correctly.  BTW, the div tag is used because NS does not support the ID
attribute in img tags, and I'm trying to get everything on my site W3C/x-browser
compatible without having to use different pages or tons of js to rewrite the
docs on the fly.

This same menu is at http://www.vortxweb.net/ccs-pg/holidays/mz_aprilfool.shtml
and will display the correct behavior in all cases.  The only difference is that
this page includes the ID attribute in the img tag.  All the CSS styles and JS
are embedded in the aprilfool page if you want to see more of the code.  They
are external files in the index page.  The fact that they are external has no
relevance, because I already tested that.  The ID in the img tag seems to be the
key.

for http://www.vortxweb.net/ccs-pg/mz_index.shtml
Correct behavior (have not seen any incorrect behavior doing this):
1. Mouseover the menu button approaching it from the right side. The other
buttons will appear.
2. Mouseout to the right of the menu button. The other buttons remain visible
and can be utilized.
3. Mouseover the menu button again approaching it from the right side. The other
buttons will disappear.
4. Mouseout to the right again. The other buttons remain hidden.

Incorrect behavior:
1. Mouseover the menu button approaching it from the right side. The other
buttons will appear.
2. Move the cursor down towards the 'home' button. The other buttons will likely
disappear before you can do anything with them.
   - or -
1. Mouseover the menu button approaching it from beneath. The cursor changes to
a hand, but the other buttons do not appear.
2. Click on the menu button. The other buttons appear.
3. Move the cursor down towards the 'home' button. The other buttons will likely
disappear.

There are other variations to this weirdness, too, like, after the other buttons
appear, mouseover the menu button from beneath it and the other buttons will not
disappear.  Actually they do, but then reappear because the setMenu function is
called more than once and the swap is done so quickly that it may not be
noticeable. Whether the other buttons show or hide in any of these "incorrect
behavior" cases depends on how many extra times the setMenu function runs.

I'm assuming it's related to the multiple mouse enters described above, but why
in only certain directions???

Comment 14

[Gervase Markham [:gerv]]

Adding testcase keyword. I'm not getting any events _at_all_ on 20000609. joki - 
what's the plan here?

Gerv

Comment 15

[joki (gone)]

I tested this last week and also got no events at all which was very odd.  I'd 
guess someone messed something up briefly but they seem to have fixed it.  All 
these cases are working for me now.

Comment 16

[luis rincon]

verified on build 2001-08-06-trunk

Comment 17

[Jerry Baker]

Mass removing self from CC list.

Comment 18

[Jerry Baker]

Now I feel sumb because I have to add back. Sorry for the spam.