236925 - Browser incorrectly responds to mouse events around iframes

Status: RESOLVED DUPLICATE of bug 125386

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

Description

[Stephen Oberholtzer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219

Note: This bug is almost certainly the cause of 136527 as well; however, mine
doesn't deal with JavaScript at all.  I'm placing this in 'Event Handling'
because if the 136527 person's guess is correct, it's actually an error
responding to mouse events.

The browser (I'm pretty sure it's Gecko itself, because the problem happens in
both Mozilla and Firefox) handles ':hover' very strangely when iframes are
entered into the picture.  Imagine an absolutely positioned 'div' that
ordinarily has the style 'display: none' (think CSS/DHTML menus). When the div
appears and overlays an iframe, the div vanishes (as if it was no longer
hovered) as soon as the cursor enters the part where the div overlaps the iframe.

The exact opposite behavior is seen, however, when the div is always visible;
once the cursor hits the point where the div overlaps the iframe, the cursor can
be moved anyplace on the iframe, and the div will remain in ':hover' state, as
if the iframe were inside the div (which it's not).



Reproducible: Always
Steps to Reproduce:
1. Load up the testcase page in Firefox or Mozilla.
2. Move your cursor over the 'this div should always be visible' text.  It will
turn bold. Move your cursor down to the portion overlapping the iframe, and then
move the cursor *off* the div onto the iframe.  The div's text will remain bold,
as if you were still hovering over it, which you are NOT.

3. Move your cursor over the div with the blue dotted border.  A second div will
appear.  Move the cursor down to where the div overlaps the iframe.  This time,
the div will vanish as if you'd taken your cursor off of it (which you haven't).


Actual Results:  
In step 2, the div remains in ':hover' state even after the cursor was removed
from it.
In step 3, the div exits ':hover' state as soon as the cursor enters the region
overlapping with the iframe.

Expected Results:  
In step 2, the div should exit ':hover' state when the cursor is moved off the
div and onto the iframe.

In step 3, the div should remain in ':hover' state while the cursor is still on
top of it.

Comment 1

[Stephen Oberholtzer]

Attachment: Testcase demonstrating bug.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this a regression, or has it always been a bug in Mozilla?

Comment 3

[Stephen Oberholtzer]

Other similar bugs seem to indicate that this bug has been around for a long, 
long time.

I also have some additional information on what's going on:

When the cursor travels over one of the popups' across the iframe border beneath 
it, the containing frame/window gets a NS_MOUSE_EXIT message.

This explains why the 2nd popup vanishes as soon as the cursor crosses the 
border; however, I can't explain why the first one stays bold.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, I think this is a dupe of a very old bug that is assigned to me. I can't
find it right now. The problem is that NS_MOUSE_EXIT events fire when we cross
native widget boundaries, and those turn into DOM mouseouts, even if the cursor
is still actually over the same element.

Comment 5

[Jason Barnabe (np)]

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

Comment 6

[Jason Barnabe (np)]

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

Comment 7

[Alex Hirzel]

Changing OS/Hardware to All/All (comment #5 and my own observations.)

Comment 8

[José Jeria]

Dupe of bug 125386?

Comment 9

[Andrew Schultz]

only drivers can set (+) blocking flags.  you can request (-) them

Comment 10

[Andrew Schultz]

is anyone still seeing this?

Comment 11

[José Jeria]

This has been fixed. Please reopen if y ou can reproduce with a nighlty trunk build.

*** This bug has been marked as a duplicate of 125386 ***

Comment 12

[Timothy C. Quinn]

Sweet - Even seemed to get rid of some other layer issues that I've been seeing.

Take the rest of the day off!

:]