Browser incorrectly responds to mouse events around iframes

RESOLVED DUPLICATE of bug 125386

Status

()

Core
Event Handling
RESOLVED DUPLICATE of bug 125386
13 years ago
3 years ago

People

(Reporter: Stephen Oberholtzer, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
Created attachment 143404 [details]
Testcase demonstrating bug.
Whiteboard: DUPEME
Is this a regression, or has it always been a bug in Mozilla?
(Reporter)

Comment 3

13 years ago
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.
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

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

Comment 6

13 years ago
*** Bug 240115 has been marked as a duplicate of this bug. ***
Changing OS/Hardware to All/All (comment #5 and my own observations.)
OS: Windows 2000 → All
Hardware: PC → All

Comment 8

13 years ago
Dupe of bug 125386?

Updated

13 years ago
Flags: blocking1.8a+
Flags: blocking1.7+

Comment 9

13 years ago
only drivers can set (+) blocking flags.  you can request (-) them
Flags: blocking1.8a+
Flags: blocking1.7+

Comment 10

12 years ago
is anyone still seeing this?

Comment 11

12 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Comment 12

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

Take the rest of the day off!

:]

Updated

3 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.