Last Comment Bug 236925 - Browser incorrectly responds to mouse events around iframes
: Browser incorrectly responds to mouse events around iframes
Status: RESOLVED DUPLICATE of bug 125386
:
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: events
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Mentors:
: 240115 240973 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-09 09:28 PST by Stephen Oberholtzer
Modified: 2014-01-16 08:33 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase demonstrating bug. (2.15 KB, text/html)
2004-03-09 09:29 PST, Stephen Oberholtzer
no flags Details

Description Stephen Oberholtzer 2004-03-09 09:28:33 PST
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 2004-03-09 09:29:09 PST
Created attachment 143404 [details]
Testcase demonstrating bug.
Comment 2 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-15 23:26:13 PST
Is this a regression, or has it always been a bug in Mozilla?
Comment 3 Stephen Oberholtzer 2004-03-16 06:26:17 PST
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) 2004-03-16 10:47:46 PST
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) 2004-05-04 15:48:10 PDT
*** Bug 240973 has been marked as a duplicate of this bug. ***
Comment 6 Jason Barnabe (np) 2004-05-04 15:51:04 PDT
*** Bug 240115 has been marked as a duplicate of this bug. ***
Comment 7 Alexander 'Chewie' Hirzel 2004-05-04 19:34:57 PDT
Changing OS/Hardware to All/All (comment #5 and my own observations.)
Comment 8 José Jeria 2004-05-19 03:03:06 PDT
Dupe of bug 125386?
Comment 9 Andrew Schultz 2004-05-19 09:32:32 PDT
only drivers can set (+) blocking flags.  you can request (-) them
Comment 10 Andrew Schultz 2005-04-20 20:54:29 PDT
is anyone still seeing this?
Comment 11 José Jeria 2005-04-21 00:42:24 PDT
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 2005-04-21 14:37:05 PDT
Sweet - Even seemed to get rid of some other layer issues that I've been seeing.

Take the rest of the day off!

:]

Note You need to log in before you can comment on or make changes to this bug.