dpointer/handlers/mouse: in Chrome and IE9, pointermove events are emitted continuously even if the mouse doesn't move

[AdrianVasiliu]

In some browsers, pointermove events are emitted continuously even if the mouse doesn't move. Found on Chrome 32 and IE9, both on Win7, while I don't get this issue on FF 27/Win7 nor IE10/Win8.

How to reproduce:

1. Copy https://github.com/AdrianVasiliu/dpointer/blob/mouseissue/tests/capture/mouse.html in the tests/capture directory and run it on desktop in Chrome 32 or IE9.
2. Place the mouse cursor inside the container (as written in the GUI) and do not move the mouse anymore.
3. Check the message area below.
   => On Chrome 32 and IE9, pointermove events are continuously received.

[seb-pereira]

I try on Chrome 32 (Ubuntu + Windows2008Server) and IE9 (Windows2008Server) with the test file mouse.html and I can't reproduce the issue you describe. I am about the get a Win7 environment to perform some more tests.

• Could you replace pointermove with mousemove in your event listener and retry the test? I'd like to make sure this is not caused by native mouse events.
• After you release the mouse, is the pointer on the screen keep moving while the events are received?
• Does the coordinates of the events are all the same?

[AdrianVasiliu]

For the log, after chatting and live debugging with Sébastien:

• Yes, the issue is the same with mousemove instead of pointermove.
• No, the pointer doesn't move while the events are received.
• Yes, the coords are all the same.

Moreover, I confirm that exactly the same issue holds in Dojo 1 (that is when using dojo/touch). For instance, with a ScrollableView on Win7 in Chrome or IE9, during a scrolling gesture using the mouse, scrollable.onTouchMove gets called continuosly even if the mouse doesn't move at all.

[cjolif]

so this sounds like actually a browser "bug" or "weird behavior" and so we should close that issue?

[AdrianVasiliu]

yes, it seems so. Thus I'm closing it.