Erratic mouseenter/mouseleave events
Project Member Reported by firstname.lastname@example.org, Mar 24 2015
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
Mar 24 2015,
IE10 and Firefox 36 behave perfectly: no redundant/missing mouseenter's or mouseleave's.
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().
Mar 25 2015,
Mar 30 2015,
Issue 333868 has been merged into this issue.
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.
Apr 1 2015,
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.
Apr 8 2015,
- 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