Bug 11705 – PlatformMouseEvent "current event" handling is bogus

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Brett Wilson (Google)]

The constructor PlatformMouseEvent::PlatformMouseEvent(const CurrentEventTag&) gets the current event from nsApp and creates a mouse event from it. However, this is only valid when the currently handled event is a mouse event. When it is not a mouse event, the mouse position will be undefined in the nsEvent.

Usually, this code is called from mouse event handlers so that's fine. Currently, it is also called from the hoverTimer callback in the EventHandler. The current event is likely to not be a mouse event, yet a PlatformMouseEvent is still created from the current event.

EventHandler has a currentMousePosition() from the last mouse event which can be used in synthesizing a new mouse move event.

[Brett Wilson (Google)]

See also bug 4117

[Brett Wilson (Google)]

Is the current mouse position even what we want? Say I have another window partially obscuring an element with :hover set to something. I move the mouse from the other window, over the element and back to the window, the element will light up (or whatever the style says) when I move over it, and it will go back when I move the mouse over the other window.

This is true even if the mouse is over the element but it is obscured by the other window, so you can't use the current mouse position, nor do you want the previous mouse position. You don't even want the last mouse message (probably some kind of "leaving the window" message) because the DOM mutation that caused this event could occur when the mouse is not in the window at all.

I think what we want is a test to see if the mouse is in the window and not obscured (possibly by testing to see if we got a "leaving" message since the last mouse move), and only then synthesizing a mouse move from the current mouse position.

[Brett Wilson (Google)]

It appears WebKit doesn't handle the case where the mouse leaves the window, so replaying the previous mouse move event (NOT the current mouse position, which might be different if we moved into another window) is likely the right thing.

See bug 13218 for a case where using the current event is disastrous.

PlatformMouseEvent::currentEvent was eliminated in <http://trac.webkit.org/projects/webkit/changeset/20753>. (Although I noticed that some leftovers resurfaced when the Windows branch was merged).