128097 - onmouseout fires inside a <DIV>

Status: VERIFIED WONTFIX

(Core :: DOM: Events, defect, P2)

Description

[Matthias Versen [:Matti]]

win2k build 20020226..

1. Load the attached testcase
2. click on Test
3. A <Div> hidden with CSS appears
4. Move the mouse inside the Div-Element -> onmouse fires inside the Box

works with IE5.0

Comment 1

[Matthias Versen [:Matti]]

Attachment: testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

The onmouseout fires when the mouse moves over the text inside the div... 

Comment 3

[Samuel Sieb]

In Matti's original testcase, the onmouseout fired when the mouse left the text.

Comment 4

[Bob Clary [:bc] (inactive)]

http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MouseEvent

<quote>
In the case of nested elements mouse events are always targeted at the most
deeply nested element.
</quote>

Do we really want to fire mouseover/mouseout on #text nodes? The spec is
actually ambiguous and this just causes us pain, doesn't it?

Comment 5

[Matthias Versen [:Matti]]

Attachment: Testcase without padding

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is a problem on many sites with menus and makes menu use on these sites
impossible.  Nominating.

Comment 8

[/\/\arcio Galli]

Tom, 

I am nominating topembed. This bug is very very important. Do you think this is
tough of would be affecting other area?? if we fix? Sites do a lot of menus
using the following approach: 

* they create one panel (layer, div, etc) 
* when you stay with the mouse in the div area, the menu is ther
* when you move the mouse outside the area, the div hides. 

We are evangelizing sites to support Gecko DOM1/2 as the workaround to IE and
4.x model. For example, we tell companies to not use Layers and serve DIV and
DOM1&2 for Gecko. This fix is a must need for evangelism. 

Added Jaime due to importance to evangelism (Gecko version of sites that are
using menus). 

Comment 9

[Robert Kieffer]

So, to throw in DIG's $.02 here...

I don't believe this is a serious bug... and, in fact, I think you can make a
good argument that the NS behavior is "more correct" than IE's.

I understand Marcio's concern about this breaking menus, but I think the reality
is that this won't a big problem.  The reason is that IE and NS exhibit the same
behavior for all elements *except* text nodes... anytime the mouse is moves over
another element (even one contained within the srcElement), a mouseout event is
generated.  IE, for some reason, decided not to do this for text nodes.

(FWIW, I've attached a test case that illustrates how IE "breaks" in the same
fashion if you have the text in a span element.)

Because most menus will have more than text nodes in them (i.e. they'll have
links, spans, divs, and other elements) developers are going to have to handle
the problem of a mouseout being generated while the mouse is still physically
within the bounds of the menu element.  (The solution is to walk up the
parentNode chain of the event's 'toElement' (on IE, or 'relatedTarget' on NS) to
determine if the element is contained within the menu div.)

Anyhow, I believe the current NS behavior is correct and reasonable.  Whether or
NOT the IE behavior is a bug can be argued.  In most cases where this is an
issue though, developers are going to have to write code to handle it anyway.

Comment 10

[Robert Kieffer]

Attachment: Test that shows how IE "breaks" in the same fashion if the text is in a span

Comment 11

[Felipe]

See www.interplay.com for a real-life example of this bug making site 
navigation basically impossible. Is any functionality broken by making Mozilla 
behave as IE 6 does in this regard?

Comment 12

[saari (gone)]

topembed+, another mouseout issue, may be covered under another bug

Comment 13

[joki (gone)]

I tend to agree with Robert Kieffer on this one.  There are sites which will
have problems with this bug if the div had anything in it besides text they'd
have to code around it anyway.  Text nodes are valid event targets under the
DOM2 Event spec and the fact that they receive events wasn't accidental.

You can continue to evangelize the use of DOM1&2 code to achieve this behavior.
 The code in question isn't robust enough to function within both IE and NS6 but
it could with a bit more code, all of which is DOM2 code.

I think our behavior is better but I can't speak to how important cloning IE's
behavior is to us on something that can be coded around easily enough.  As far
as what would be broken by changing to suit IE's behavior it's pretty much
always true that changing behavior will break something somewhere, even if it
fixes something else.

Comment 14

[saari (gone)]

seems we have better/correct behavior then.

Comment 15

[Vladimir Ermakov]

verifying