236080 - onMouseout event is not fired everytime if there are two divs one upon the other

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Eino Akkila]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:) Gecko/20040229

I created a simple menu using a bit of javascript and css but run into problems.
onMouseout event is not fired everytime when it should.
If there are two divs overlapping each other and mouse pointer exits div area
where overlapping is happening the problem occurs.
Menu will leave open sometimes even though it should close.

The subber div is the one which is trying to fire events.

Reproducible: Always
Steps to Reproduce:
Ok, I have included my html file as an example
1. move your mouse over the "Menyy"-text from right to left.
2. sub menu will open. Now exit the "E is a good letter"-text from left side of
the menu.

Actual Results:  
Menu will stay open. If you exit the menu from grey area it will always close.

Expected Results:  
The menu should have closed. This is what happens with IE 5 to 6 and with Opera
7. Haven't had the change to test other browsers yet.

Comment 1

[Eino Akkila]

Attachment: Html example (just in case my webspace is not working)

Comment 2

[Jesiah S]

I see this on LInux 2004032708 but I don't see the second DIV.  Also, I think
I've seen this before.

Comment 3

[Juliusz Gonera]

Confirming, experienced it when making my newest design: http://jgonera.abc.pl/.
Try moving mouse over "PROJKTY" and "OFERTA", it wan't disappear each time it
should.

Comment 4

[Juliusz Gonera]

Sorry, forgot about UA:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040411
Firefox/0.8.0+ (BlueFyre)

Comment 5

[Fredrick Knieper]

Attachment: Advanced testcase with debugging output

Comment 6

[Fredrick Knieper]

Semi-Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
Gecko/20040803 on XP SP1.

Slightly misleading bug title.  The example given by Akkila certainly
misbehaves, but it only has a single div, there are no overlapping <div>s here.

I attached a variation of that example adds some debugging information which
should help ferret out the real problem here.  For instance, the mouseOut events
are only triggered every other <a> tag as you mouse down the menu.  onMouseOver
events are triggered as scheduled, however.

For maximum confusion I've thrown in some other elements to see what happens.
The button ("B") has mouseover events but never a mouseout event, however the
main mouseout always fires when entering B.  The input ("I") fires too many
mouseover events when entering or exiting.  "Text" never fires a mouseout for
the span "S", but always fires a Main mouseout.

Now, if I type something into the input, suddenly the <a> tags fire mouseouts
every time, the button fires a mouseout every time, "Text" fires a mouseout for
the span... the only thing this doesn't fix is the extra mouseouts for the
input.  If I erase the text in the input, the behavior returns to the broken
version.

This does bring up a question, is it the JS spec to send onMouseOut events to
the parent object when entering a nested object?  IE does this as well (though
the debug script causes IE issues on load for some reason), triggering an
onMouseOver immediately after the onMouseOut, Mozilla tries to do the same, but
on this example on this system at least, there is a noticable flicker in the
menu as it does so. (IE has issues with this code for some reason, I got it to
finish loading by hitting esc after IE freezes)

Comment 7

[Simon Hawkin]

Attachment: Another example of bug 236080 or similar

Bug described in my message.

Logging turns the bug off somehow. (Un)comment the "return" at the beginning of
the debug.log function to toggle behavior.

Comment 8

[Simon Hawkin]

Comment on attachment 160810 [details]
Another example of bug 236080 or similar

(In reply to comment #6)
> Semi-Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
> Gecko/20040803 on XP SP1.

I came across this bug when generating a large "tooltip" TT that (1) appears
when the cursor enters a container element EL, (2) stays on while the cursor is
on top of either EL or TT, and (3) disappears otherwise. TT is created by
javascript as a 'div' element, child of EL, the first time the cursor enters
EL, and placed at a certain location (the value of property position is
absolute). Afterwards, TT is shown or hidden via manipulation of the display
property (with the value of block or none, respectively).

Here is what happens. Suppose TT is situated so that a portion PB of its border
is outside the borders of EL. Then the first time I am moving the cursor
through PB (out of TT), onmouseout event is not generated for TT. Now I can
move the cursor back in TT through PB (without moving it via EL) or through EL.
In the former case, moving the cursor again out of TT through PB generates
onmouseout (so the tooltip disappears), in the latter case, onmouseout is still
not generated.

Complication. When I added a debug log in a textarea to monitor the
event-triggered control flow, the code started behaving properly.

Behavior is observed on Win XP and Win 2003 Server.

> This does bring up a question, is it the JS spec to send onMouseOut events to
> the parent object when entering a nested object?  IE does this as well (though
> the debug script causes IE issues on load for some reason), triggering an
> onMouseOver immediately after the onMouseOut, Mozilla tries to do the same, but
> on this example on this system at least, there is a noticable flicker in the
> menu as it does so. (IE has issues with this code for some reason, I got it to
> finish loading by hitting esc after IE freezes)

I wonder about that too, although my code seems to be working on IE.

Comment 9

[Simon Hawkin]

This is a minor addition: another way to keep debug log does not interfere with
the bug.

> Created an attachment (id=160810)
> Another example of bug 236080 or similar

> Bug described in my message.

Can use the following debug.log function instead of the one in attachment. It
keeps the log in a separate window. The bug is not affected then.

debug.log = function (txt)
{
  if ('undefined' == typeof thelog || !thelog) {
    thelog = top.debugLog = window.open ('', 'debug log');
    if (!thelog) {
      alert ('***Cannot open debug log window');
      return;
    }

    thelog.document.writeln (
      '<html><body style="\n'
      + '  font-family: monospace; font-size: 9px;\n'
      + '">\n' + '<div id="thelog" >DEBUG LOG started ['
      + new Date().toString().substring (0,24) + ']</div>\n'
      + '</body></html>'
    );
    thelog.document.close();

    thelog = top.debugLog.document.getElementById ('thelog');
    if (!thelog) {
      alert ('***Cannot open debug log div');
      return;
    }
  }

  eol_ornot = '<br >\n';
  if (arguments.length > 1)  {
    eol_ornot = '';
  }
  thelog.innerHTML += eol_ornot + txt;
}

Comment 10

[Sergey Sokoloff]

Bug 220902 should probably be marked as a duplicate of this bug, and summary
here updated to include "detected" and "popup" keywords, to make bugzilla search
easier.

Ad, if someone is interested, I still see the same bug in Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Comment 11

[Wolf [:wolf]]

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

Comment 12

[Sergey Sokoloff]

After some additional tests I've found that this bug affects not only the
JavaScript implementation of onMouseOut event, but also one of the most useful
CSS2 pseudo-classes, :hover.

This is serious. There is no workaround for this bug, even if the webpage is
rewritten to be based on CSS2 dynamic pseudo-class instead of JavaScript dynamics.

Eino Akkila, if you're still nearby, please update summary to reflect this
fact... maybe something like this:

onMouseout event is not fired everytime if there are two divs one upon the other
(e.g. popup menu); CSS2 :hover pseudo-class is applied but not undone

Comment 13

[Sergey Sokoloff]

Great news:

WFM in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+

(this is Deer Park Alpha 1 Developer Preview)

Popup menus are pretty clean in this version and have faster look'n'feel.

Comment 14

[Fredrick Knieper]

I can confirm that the broken behavior is fixed in the three test cases here in
Windows's Deer Park 1: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050531 Firefox/1.0+

Can someone attach a test case (or a link to a site using it) for the :hover
attribute issue?

I noticed the behavior I noted in #6 is still there when entering and exiting a
nested element.  Moving into a menu item fires the main menu's onMouseOut,
followed (eventually) by the main menu's onMouseOver.  The input tag still
generates two pairs of mouse events when entering/exiting (it seems that the
events are a pixel apart... one event is fired the instant the cursor is changed
to the "I" text cursor (over the border of the input box), another is fired when
the I cursor is moved into the actual input area.  

Comment 15

[Daniel Kabs, reporting bugs since 2002]

Testcases on nightly build
- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050829 Firefox/1.6a1

WFM.

Comment 16

[Daniel Kabs, reporting bugs since 2002]

Checked testcases with BRANCH nightly build
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050827 Firefox/1.0+

WFM.

Looking forward to Firefox 1.5 :-)

Comment 17

[Sergey Sokoloff]

So nothing is ruined here since Deer Park Alpha 1?

Good news.

Reporter (Eino Akkila), can you confirm and close this bug as WFM FIXED?

Comment 18

[Eino Akkila]

New beta versions fixes the problem. Thank you mozilla team and everyone else
who confirmed this bug and helped the fixing progress!

Comment 19

[Kevin Brosnan]

Fixed is only for bugs where we know what the patch was. Since we don't know
worksforme.

Comment 20

[Eino Akkila]

ok then.