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
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).
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).
In step 2, the div remains in ':hover' state even after the cursor was removed
In step 3, the div exits ':hover' state as soon as the cursor enters the region
overlapping with the iframe.
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.
Created attachment 143404 [details]
Testcase demonstrating bug.
Is this a regression, or has it always been a bug in Mozilla?
Other similar bugs seem to indicate that this bug has been around for a long,
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.
*** Bug 240973 has been marked as a duplicate of this bug. ***
*** Bug 240115 has been marked as a duplicate of this bug. ***
Changing OS/Hardware to All/All (comment #5 and my own observations.)
Dupe of bug 125386?
only drivers can set (+) blocking flags. you can request (-) them
is anyone still seeing this?
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 ***
Sweet - Even seemed to get rid of some other layer issues that I've been seeing.
Take the rest of the day off!