即使鼠标未在chrome上移动，也会触发mousemove事件 [英] mousemove event is triggered onscroll even when mouse was not moved on chrome

问题描述

我试图回答自定义下拉的问题，但在Chrome和FF中的行为不一致。

DEMO：

在你的例子中，我发现当鼠标悬停在<$>上时，Chrome和FF都会触发 mouseenter DOM事件c $ c>< ul> ，然后按下按键会触发浏览器滚动以使所选< li> 。

但是，只有Chrome才会触发 mousemove 事件。在 mouseenter 事件对象中有一个明显的区别，那就是对于Chrome， MouseEvent.offsetX 和 MouseEvent。包括offsetY 值，而在FF中，这些属性是 undefined 。所以，当这个输入被触发时，Chrome已经决定鼠标已经移动了。

$ b 由于 MouseEvent.screenX 和 MouseEvent.screenY 事件上下文值在滚动触发 MouseEvent 实例之间不会改变， 人造mouseenter / mousemove 事件，以及通过存储以前事件中的这些值的真实事件。

DOM Event Specification

DOM级别2鼠标事件规范读取：

当移动指针设备时发生mousemove事件而它是一个元素。

3级规范（工作草案）基本上是一样的：

用户代理程序必须在指针设备移动到元素上时调度此事件。看起来好像可以解释一个人是否相对移动了。

另外，在关于鼠标事件顺序的Level 3规范部分，它指出当一个指针移动到一个元素中时，它会依次触发鼠标悬停，鼠标和鼠标移动。每个在那里指定的案例总是有三个在一起，所以也许有人可能会认为，如果你要触发 mouseenter 事件，你也应该触发 mousemove 事件，相当于输入元素。

I was trying to answer an issue with custom drop down, but challenged by an inconsistent behavior in Chrome and FF.

DEMO: http://jsfiddle.net/fyeht/ [Added scroll event for more clarity]

See below image, The list items can be navigated using arrow keys.

To Reproduce the issue:

1. Open console in Chrome (F12)
2. Click on an item in the list (you would notice some events getting logged in the console)
3. Use down arrow key to navigate to the next item in the list
4. Finally, the issue is noticed when you reach the last item in the view and hitting down arrow would scroll. Check the log to see 'scroll', 'mouse enter' and 'mouse move' [check the new demo]

The issue is after reaching the end of items in view, it scrolls. Even though the mouse is untouched, it triggers mouseenter and mousemove events in Chrome. In FF, on scroll it triggers just the mouseenter which make sense.

Question(s):

• Why is mousemove triggered when mouse is untouched?
• Is this just browser inconsistency? Could not find documentation on events triggered when scrolling? (never knew it did)

Submitted a bug report: https://code.google.com/p/chromium/issues/detail?id=241476

解决方案

In your example, I see that both Chrome and FF are firing mouseenter DOM events whenever the mouse is left hovering over the <ul> and pressing the key down triggers the browser to scroll in order to bring the selected <li> into view.

However, only Chrome is additionally triggering mousemove events. One obvious difference already in the mouseenter event objects that the two throw is that for Chrome, MouseEvent.offsetX and MouseEvent.offsetY values are included, whereas in FF these properties are undefined. So, when that enter is triggered Chrome has already decided the mouse "has moved".

Since the MouseEvent.screenX and MouseEvent.screenY event context values do not change between scroll-triggered MouseEvent instances, one could perhaps distinguish between an "artificial" mouseenter / mousemove event and an "authentic" one by storing these values from prior events.

DOM Event Specification

The DOM Level 2 Event Specification for mousemove reads:

The mousemove event occurs when the pointing device is moved while it is over an element.

The Level 3 spec (working draft) is essentially the same:

A user agent must dispatch this event when a pointing device is moved while it is over an element.

Seems like it could down to whether one interprets "is moved" relatively or not.

Also, in the section of the Level 3 spec on mouse event order, it states that when a pointer is moved into an element, it triggers mouseover, mouseenter, and mousemove, in that order. Every case that is specified there always has those three together, so perhaps one might interpret it that if you are going to trigger the mouseenter event, you should also be triggering the mousemove event which corresponds to entering the element.

这篇关于即使鼠标未在chrome上移动，也会触发mousemove事件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！