New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users

Issue metadata

Status: Fixed
Closed: Apr 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

issue 457497

Sign in to add a comment

Issue 470258: Erratic mouseenter/mouseleave events

Reported by, Mar 24 2015 Project Member

Issue description

On certain mouse events, chrome sends too many/too few mouseenter/mouseleave events, breaking the enter-vs-leave pairing assumption. Here is a really bad case:

1. Go to .
2. Click-and-hold on yellow.
3. Drag to any other color.

We shouldn't see yellow mouseenter's (expect possibly the very first one, depends on past mouse position).

We see many yellow mouseenter's in a row, perhaps one-per-mousemove.

Other actions that could potentially trigger this behavior include:
- Context menu popup (I could repro once)
- Frame resizing (unverified).

In fact, this should happen whenever EventHandler::dispatchMouseEvent() is called with setUnder=false, because of the conditional update of m_lastNodeUnderMouse:

Comment 1 by, Mar 24 2015

IE10 and Firefox 36 behave perfectly: no redundant/missing mouseenter's or mouseleave's.

Comment 2 by, Mar 25 2015

It seems that the state variable EventHandler::m_lastNodeUnderMouse should be removed, for two reasons:
- It is a misnomer: it is the same as m_nodeUnderMouse after a dispatchMouseEvent() call with setUnder=true, but retains its value after a dispatchMouseEvent() call with setUnder=false. Therefore, it could be any node that ever came under mouse!
- Except one use in handleMouseReleaseEvent(), it is used only in updateMouseEventTargetNode().

Comment 3 by, Mar 25 2015

Blocking: chromium:457497

Comment 4 by, Mar 30 2015

 Issue 333868  has been merged into this issue.

Comment 5 by, Mar 30 2015

Thanks for digging into this Mustaq!  The more you can simplify this stuff the better IMHO.  As you know there can be a lot of subtle behavior wrt. interaction of mouse events which pages can come to depend on.  It might be worth a trip down 'git blame' history to see who added this logic and when to make sure removing it won't regress anything valuable.

Comment 6 Deleted

Comment 7 by, Apr 1 2015

The fix for a related event-ordering bug ( ) has resolved the main problem here: redundant mouseenters on drag.

I have piggy-backed the test for this bug that CL. See fast/events/mouseenter-mouseleave-on-drag.html in

It remains to verify if (after the patch above) we can repro the bug on context-menu or frame-resizing.

Comment 8 by, Apr 8 2015

Status: Fixed
- Just verified that the context-menu case is also fixed now.
- Couldn't repro the additional suspected case of inconsistency in event sequence during frame-resizing.
- See the last post about the main issue (redundant mouseenters on drag).

Sign in to add a comment