9456 - [PP]DOM Event listeners don't get MouseOut events when mouse leaves window

Status: VERIFIED FIXED

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

Description

[Mike Pinkerton (not reading bugmail)]

I have a DOM event listener on a button (implements nsIDOMMouseListener). Mousing
into the button fires a "MouseOver," mousing out gets a "MouseOut." This all
works just fine.

However, if the mouse exits the button into another window (another browser
window, for example, or a tooltip) placed right next to the button, the button
never gets the "MouseOut" event until the mouse comes back into the original
window.

This is MacOS only. Linux and win32 do the right thing, it appears.

Comment 1

[White-Gandalf]

Seems to be identical to 5519!


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

Comment 2

[Mike Pinkerton (not reading bugmail)]

It's a different problem. reopening.

Comment 3

[leger]

Putting on [PP] list.

Comment 4

[joki (gone)]

Well I'm not sure about Linux but I know the reason this works on Windows is
that we had to set up a NS_MOUSE_EXIT event when the mouse left a window.  This
is not something that Window's sends native and I believe it had to be
accomplished through a timer set up during mousemoves which rechecked the mouse
location after a certain period.

Its conceivable that this could be fixed in an xp way but I think it would be
hard.  For presShells living under the same parent its not too bad but after
that you have to start enumerating all the webshells and notifying each of them
that the mouse is over you now and have them each notify their children?  Yuck.
I think that Mac should probably start sending a mouseexit event like the
others.  That ends up as Mac widget work that I'm not likely to do myself.
Pierre?  Pink?

Comment 5

[Stuart Parmenter]

X loves us (this must be a first as I have never seen X love me before.) and
does this lovely feature for us.

Comment 6

[Peter Trudelle]

Pink, if this is a blocker, please mark severity as such. Also, joki, this badly
needs triaging, can we resolve it in M10?

Comment 7

[Peter Trudelle]

pink, pierre: have you talked with joki about doing this native on the Mac?

Comment 8

[joki (gone)]

This has been kind of just rotting here for a while.  I haven't been working on
it since its a Mac widget fix but its still assigned to me since I haven't
found the right Mac widget person to give to to yet.  I'll ask again, Pink?
Pierre?  The basic need here is for the widget library to fire a mouseout event
when the mouse leaves the window.  On Windows we do this with a timer, on X
there is a system event for it.  Needs some kind of Mac solution, probably the
same as the Windows solution.

Comment 9

[Mike Pinkerton (not reading bugmail)]

yeah, probably a timer. i'm swamped right now. maybe dcone should get this.

Comment 10

[Pierre Saslawsky]

The problem is that we have one nsMacEventHandler per nsMacWindow (see
nsMacWindow.cpp, line 260) and that the 'MouseIn' and 'MouseOut' events (aka
NS_MOUSE_ENTER and NS_MOUSE_EXIT) are generated by the nsMacEventHandler when the
mouse points to a different widget (see nsMacEventHandler.cpp, line 953). As a
result, when the mouse points to a different window, the previous window is not
notified and its nsMacEventHandler.cpp doesn't generate the NS_MOUSE_EXIT
message).

Maybe we should handle the widget that's being pointed by the mouse in a similar
way to the widget that has the focus (see nsToolkit.cpp).

CCing Don Cone.

Comment 11

[Peter Trudelle]

setting severity back to blocked (what happened to it?) and cc'ing rickg

Comment 12

[joki (gone)]

Per pierre, comment, previous windows are not notified on Windows either.
That's why we put in a timer to query window location to see if it had entered
another window which was not getting the messages.

Anyway, still no one claiming this and I still don't do native Mac widget
code so I'm just going to toss it to someone.  Pierre, you unluckily commmented
last.

Comment 13

[Pierre Saslawsky]

Fixed in nsMacEventHandler by changing mLastWidgetHit and mLastWidgetPointed to
static variables.

Comment 14

[Mike Pinkerton (not reading bugmail)]

the test case is a tooltip, which doesn't seem to be working just yet. i don't

think hyatt has landed the changes to get them back up and running. of course,

tooltips aren't part of beta, so......

Comment 15

[Pierre Saslawsky]

On my part, I tested the fix by moving the mouse over the buttons of 2 browser

windows:

- open a window A in the foreround and a window B in the background

- make sure that window A covers half of a toolbar button from window B

- move the mouse from over that button to over window A

==> Before the fix, the button from window B was staying hilited. After the fix,

it is de-hilited.



It was possible to reproduce the bug through other ways and I checked that the

fix was working for these as well.

Comment 16

[leger]

Putting on [PDT]+ radar.

Comment 17

[Mike Pinkerton (not reading bugmail)]

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

Comment 18

[leger]

Putting on M12 radar since fixed during this time.

Comment 19

[ckritzer (gone)]

Marking VERIFIED FIXED on MacOS86 1999112908 apprunner.
Also tested on:
 Linux6 1999112908 apprunner
 WinNT 1999112908 apprunner