2

I noticed mouseenter event triggered when mouse is untouched but the page below the cursor is scrolled.

Check out this fiddle: http://jsfiddle.net/F3EwW/

Steps to reproduce:

  1. Click on a li
  2. Use up/down arrow keys to scroll the items
  3. You would notice the mouseenter event getting triggered when the li below is scrolled to the view.

Note: To notice this behavior, make sure the mouse cursor is above li and leave it untouched.

Initially, I accepted this as a default behavior and went on with a work around to handle this in my code.. but then I got curious and wanted to verify this behavior in any documentation which I couldn't find it anywhere.

Does anyone know if this behavior is documented anywhere in spec or any authentic webpage?

I looked up w3spec event scroll and mouse event order, but couldn't locate anything about this.

Also the spec description for mouseenter is as follows,

A user agent must dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements. This event type is similar to mouseover, but differs in that it does not bubble, and must not be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements.

In Chrome, you would notice mouseover to be triggered as well. I have posted a question and a bug report already on this.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Selvakumar Arumugam
  • 79,297
  • 15
  • 120
  • 134
  • I can't replicate the behaviour you mentioned in Chrome or Firefox in that fiddle... – David Barker May 24 '13 at 18:19
  • @DavidBarker Did you click on the `UL` and use arrow keys to scroll? – Selvakumar Arumugam May 24 '13 at 18:20
  • 2
    yeah I did, the only way I can get anything close the behaviour you mentioned is if I leave the mouse hovered over the UL and then scroll... but then I'd expect that behaviour – David Barker May 24 '13 at 18:22
  • I'd expect this behaviour too – A. Wolff May 24 '13 at 18:23
  • @roasted Yes, I agree.. but the question actually is _Does anyone know if this behavior is documented anywhere in spec or any authentic webpage_ – Selvakumar Arumugam May 24 '13 at 18:26
  • @roasted The thing is, it bothered me when writing a workaround to handle this.. that is when I wanted to make sure of this. It could be just me and probably posted this because of what I am doing now.. I might delete this if everyone feels that it is implicit and doesn't require to be documented. However the spec says everywhere that mouse pointer has to move for any mouse event to trigger which seems contradicting to the above behavior that I am seeing. – Selvakumar Arumugam May 24 '13 at 18:33
  • You are correct and i can't find it documented anywhere too. This is interesting question for sure. – A. Wolff May 24 '13 at 18:35
  • 2
    @Vega I can see your point, must admit I was initially a little perplexed by your question... I cant find it documented anywhere either. That said, if you apply an event handler to an element rather than the cursor itself it would be listening for any mouse movement within its constraints. Whether the mouse moves or not it clearly detects it, I would say this was an unintended 'feature' that sort of makes sense. – David Barker May 24 '13 at 18:36
  • The specs only says that the event is triggered when the pointing devices is moved into or out of the element boundary. They don't state that this must happen of an actual movement of the pointing device itself. This is in my opinion an inaccuracy of the specification, because one can say that it must be an actual movement of the device, but one also can say that if the page is moved the pointing device is moved into the element. Its like saying a target moves into the view of the camera by the movement of the camera and not of the target. – t.niese May 29 '13 at 08:37
  • @t.niese No, It does. _A user agent must dispatch this event **when a pointing device is moved onto the boundaries of an element** or one of its descendent elements._ – Selvakumar Arumugam May 29 '13 at 12:55
  • @Vega yes i read that part, i just want to say that the **when a pointing device is moved** is in my option not clear enough. if the viewport is changing, you have other _x_,_y_ coordinates of the pointing device in the viewport which could be counted as movement. – t.niese May 29 '13 at 13:09
  • @DavidBarker +1 for " I would say this was an unintended 'feature' that sort of makes sense" – Neo Jul 03 '13 at 21:23
  • @Neo Just curious, did you downvote instead of upvote? – Selvakumar Arumugam Jul 03 '13 at 23:20

1 Answers1

0

You realize that you have $('li').mouseenter(function () { ? this caused the mouseenter event to be binded to each and every one of this li elements so when you are using the up and down key to scroll and your mouse is still inside the ul it keeps entering a new li. This was not an unintended feature the mouse in entering the new element.

The behaviour you are looking for is more something like this:

$("element").bind("mousemove mouseenter", function(event) {
    //...
});

Also you need to realize the DOM understands the movement of the mouse relative to the document not where your mouse is on your screen as your OS does.

Neo
  • 11,078
  • 2
  • 68
  • 79
  • The demo is specially created to demonstrate what you have stated. The question is about where is this behavior documented? The spec says _A user agent must dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements._.. but the pointing device is untouched. – Selvakumar Arumugam May 29 '13 at 13:51
  • It says "when a pointing device is moved", you seem to interpret this as "when the mouse is moved", there is a difference, when you scroll a browser, to the operation system your pointing device has not moved, to the Document Object Model it has, this documentation would have been perhaps better if it said, "when the location of the pointing device has moved"... also keep in mind that it does not bubble up the hierarchy. – Neo Jul 03 '13 at 21:22