[PP] frames don't get NS_MOUSE_EXIT events when mouse leaves window

VERIFIED FIXED

Status

()

P2
normal
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: mikepinkerton, Assigned: joki)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

When the mouse goes from a frame directly to a location directly outside the
window (say the frame butts up against the window edge) and through no other
parts of gekco, the frame does not get an NS_MOUSE_EXIT event.

This can be easily seen in apprunner by mousing over a grippy on a toolbar and
then moving the mouse directly to the left outside the window. The grippy will
remain highlighted. If you repeat this, but instead move the mouse somewhere else
inside gecko's space, it works correctly and the grippy unhighlights.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 1

20 years ago
I'm really not at all suprised.  We'll have to see which systems even give us
these events and then set up timers and such for those that don't.  I know
Windows doesn't have a notification for leaving the Window either.  I probably
won't get to this for a little while.

Updated

20 years ago
QA Contact: 4015 → 3847

Comment 2

20 years ago
*** Bug 4052 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

20 years ago
Summary: frames don't get NS_MOUSE_EXIT events when mouse leaves window → [PP] frames don't get NS_MOUSE_EXIT events when mouse leaves window
(Assignee)

Comment 3

20 years ago
Actually this works on Windows now so this would have to be a platform parity
issue, too.

Updated

20 years ago
Blocks: 7403

Updated

20 years ago
Blocks: 7893

Updated

20 years ago
No longer blocks: 7403
(Assignee)

Comment 4

20 years ago
Actually Pink, can you take a look at this?  Getting this to work on Windows,
due to the lack of a window mouseout message pretty much amounts to settting a
timer and checking for window containment and simulating the event if
necessary.  Gross but true.  The same would have to be done on the Mac but its
Mac widget code.  Or maybe it should be Pierre's or something, I don't know.
But I don't think it'll be me based on time/buglist/its in Mac code.

Comment 5

20 years ago
I still this on windows for mouse moves/exits out of the window. I also see
this problem when I drag the mouse very quickly into the content window from a
toolbar button.

The problem on windows is that it gets to the GenerateMouseEnterExit method and
even executes the exit part of the code. I think the issue is that no NEW call
to SetContentState occurs so therefore the frame with the current hover "state"
is never asked to reset itself back to a "normal" state. So how do we get the
frame with the current hover state to get set back?

I have this exact same problem for drag-exit events (mostly because it is a
direct copy of the mouse code

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 6

20 years ago
Checked in the fix for this last week. - rod

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 7

20 years ago
Appears to be fixt.
Marking verified
Build ID: 1999070708
You need to log in before you can comment on or make changes to this bug.