onmouseover, onmouseout events not sent, or sent seemingly at random

RESOLVED INACTIVE

Status

()

Core
Event Handling
--
major
RESOLVED INACTIVE
17 years ago
18 hours ago

People

(Reporter: ioquatix khankxir, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8a1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020415

Perhaps it is my error (most likely), but while making a popup menu using divs
and styles, I am seeing erratic behaviour with the event code. There are two
events used on the parent layer, onmouseover and onmouseout. When I get an
onmouseover event, I display the children menuitems. When I get an onmouseout
event, I hide them again.

The children are part of the element which receives these two events, so
supposidly if you keep the mouse over these elements, the menu should stay
visible, and only when you move the mouse out of the parent menu div should the
menu dissappear.

The code is shown below (sorry, I don't have anywhere to upload it).



Reproducible: Always
Steps to Reproduce:
Put the code in the page, and move the mouse over the 'Menu' text. The menu
should pop up, and you can usually move your mouse over it ok. Sometimes, if you
move your mouse over the children, the menu will dissappear, sometimes not. If
you move your mouse directly out of the parent div, sometimes it will close,
sometimes not.

Some interesting things I have noted - if you move the cursor directly into the
top of the menu, it opens evertime without fail. And if you then move it
directly out at the bottom, it closes without fail. Move it in from a different
place or move it out from a different place, and the state of the menu after the
movement is completly random.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style type="text/css">
body
{
 background-color: #666666;
}
.Menu
{ position: fixed;
 background-color: #9999aa; color: #ffffff;
 width: auto; height: 14px;
 left: 10px; right: auto; top: 10px; bottom: auto; }
MenuItem
{
 background-color: #ffffff;
 color: #025c7f;
}
</style>
</head>
<body>

<div class="Menu"
onmouseover="getElementsByTagName('span').item(0).style.setProperty('display','inline','');
return true;"
                 
onmouseout="getElementsByTagName('span').item(0).style.setProperty('display','none','');
return true;">    
 Menu
 <span id="SamiAm" style="display: none;">
 <div class="MenuItem">
  MenuItem1
 </div>
 <div class="MenuItem">
  MenuItem2
 </div>
 <div class="MenuItem">
  MenuItem3
 </div>
 <div class="MenuItem">
  MenuItem4
 </div>
 <div class="MenuItem">
  MenuItem5
 </div>
 <div class="MenuItem">
  MenuItem6
 </div>
 </span>
</div>
</body>
</html>
Created attachment 70492 [details]
reporter's html
(Reporter)

Comment 2

17 years ago
Created attachment 70493 [details]
new (but not obsoleting) example, fixed the size of the parent div, works slightly better, but still weird events fired/not fired
(Reporter)

Comment 3

17 years ago
Ok I have modified the code slightly. Take a look at the new attachment. That
version seems to work better, however, it does not allow for dynamic sizing of
the layers. It is weird how this dynamic sizing of the layers could have any
effect on the event handling.

http://bugzilla.mozilla.org/attachment.cgi?id=70493&action=view

I have also experimented with the code. If you move the mouse onto the text
'Menu' and then onto a 'MenuItemX' the menu items will stay open, however, if
you move the mouse from another part of the Menu layer onto 'MenuItemX' the menu
will not stay open. It appears to be some problem with the events going through
the annonymous text layer ('Menu') because this example has all the same
randomness as the previous one, aslong as you disregard the extra part of the
Menu layer on the end (ie, move the mouse into the 'Menu' text and then out, it
will behave just as randomly as the previous example).

Weird...

~c
(Reporter)

Comment 4

17 years ago
Created attachment 70702 [details]
crashes if you click on the menu too much and too quickly

This crashes mozilla if you doubleclick the menu header rapidly for about 4~5
seconds. Not sure if the problems are similar, or completly different. But very
weird.

Comment 5

16 years ago
Currently on Linux, all the testcases open properly, but will never close.  Has
anyone tested this on Windows (the bug is filed as ALL/ALL)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

16 years ago
This bug affects all version up to 0.9.9 (which was the latest version I have
tested)

Platform - Version
Windows 98SE - 0.9.9
Linux mdk8.2 - 0.9.8

Both platforms suffer from the bug, however, the windows bug is much more severe
- it is never possible to close the window, and the rollover menu buttons do not
'roll over' - they flip to white, but never move back, like they do on the linux
version.

~c

Updated

16 years ago
QA Contact: madhur → rakeshmishra
(Reporter)

Comment 7

16 years ago
The bug still exists and still exists and still affects the windows version, i
haven't tested it on linux at the newest version of moz, but it fails on both
win and mac (buildid: 2002101612)
Severity: normal → major

Updated

16 years ago
QA Contact: rakeshmishra → trix

Comment 8

16 years ago
Related to bug 24974 ?

Comment 9

16 years ago
Created attachment 115002 [details]
The onmouseover event on the maps area fires at random (seemingly)

Comment 10

15 years ago
Created attachment 128074 [details]
Simplified testcase - no styles, just plain html; visual counter that displays difference between number of onmouseover and onmouseout events, so you can see what is going on there.

Comment 11

15 years ago
.
Assignee: joki → saari
QA Contact: trix → ian

Updated

14 years ago
Flags: blocking1.8a?

Updated

14 years ago
Flags: blocking1.8a? → blocking1.8a-

Comment 12

14 years ago
This bug seems to be stagnating a bit, thought I'd add some info.  Someone was
trying to build a dropdown menu and was having problems with the onmouseout
event firing and hiding the menu at unfortunate times.

I'll attach a test case with 3 different scenarios, 2 of which have onmouseout
happening when it shouldn't.

One seems to be caused by overflow:auto being specified on the element, the
other is caused by mousing over a child element, which, to my understanding,
shouldn't trigger onmouseout.

Or if anyone has a more appropriate bug, feel free to make a suggestion!

Comment 13

14 years ago
Created attachment 169953 [details]
yet another example of the problem

Updated

13 years ago
Blocks: 289539
Created attachment 185558 [details]
Simple TestCase about same problem with mouseout/mouseover both visible


This is simplified testcase from our website which doesn't work with firefox or
suite. It is tested on windows and linux.

If somone want to test the patch in our website the address is http://cmax.gg
and user is firefox and password is firefox.

We got workaround in our development branch which is going to be ready in in a
week. We are going to delay handling of moseout with setTimeout() using 10 ms.
If no mouseover for same element is sent in 10 ms then we handle the event. But
it's still fails to work with select/option compination. 

I can post the workaround later if someone needs to see how we are trying to
stop false events.

reproduses allways

excepted behaver: no mouseover sent when mouse is over child node which is
outside of parent element and mouseover isn't sent randomly.
Assignee: saari → nobody
QA Contact: ian → events

Comment 15

9 years ago
was comment 14 testcase run at the time with the fix of 2005-04-10 from bug 289719?

why is this considered severity major?  (the change was made without comment)

crashed while playing with testcase. filed Bug 512810 crash [@ xul.dll@0x3e6edb]

Comment 16

18 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 18 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.