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

Issue 470258 link

Starred by 15 users

Issue metadata

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

Blocking:
issue 457497



Sign in to add a comment

Erratic mouseenter/mouseleave events

Project Member Reported by mustaq@chromium.org, Mar 24 2015

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 http://jsbin.com/cenoje/quiet .
2. Click-and-hold on yellow.
3. Drag to any other color.

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

Actual:
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:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/EventHandler.cpp&l=1893

 

Comment 1 by mustaq@chromium.org, Mar 24 2015

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

Comment 2 by mustaq@chromium.org, 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 mustaq@chromium.org, Mar 25 2015

Blocking: chromium:457497

Comment 4 by mustaq@chromium.org, Mar 30 2015

Cc: mkwst@chromium.org
 Issue 333868  has been merged into this issue.

Comment 5 by rbyers@chromium.org, Mar 30 2015

Cc: myid.o.s...@gmail.com
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

The fix for a related event-ordering bug ( crbug.com/470947 ) 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 crrev.com/1047733002.

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

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