Bug 11705 - PlatformMouseEvent "current event" handling is bogus
Summary: PlatformMouseEvent "current event" handling is bogus
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2006-11-28 11:59 PST by Brett Wilson (Google)
Modified: 2007-08-22 08:49 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Brett Wilson (Google) 2006-11-28 11:59:48 PST
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.
Comment 1 mitz 2006-11-28 12:09:07 PST
EventHandler has a currentMousePosition() from the last mouse event which can be used in synthesizing a new mouse move event.
Comment 2 Brett Wilson (Google) 2006-11-29 12:24:16 PST
See also bug 4117
Comment 3 Brett Wilson (Google) 2006-11-29 12:29:47 PST
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.
Comment 4 Brett Wilson (Google) 2006-11-29 14:20:33 PST
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.
Comment 5 mitz 2007-03-29 14:46:32 PDT
See bug 13218 for a case where using the current event is disastrous.
Comment 6 mitz 2007-08-22 08:49:32 PDT
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).