As per issue description and based on related issue(161464) removing the Needs-Bisect label.If it is required please add the "Needs-Bisect" label again.

Thank You!

It's been two months now.

Can confirm issue still exists in both 59.0.3071.115 and Version 61.0.3152.0 (Canary), both 64-bit.

Fixing this bug is critical for proper functioning of certain Javascript code.

Decreasing priority back to P3. This is what the native OS is delivering us I believe and certainly can match the spec. We will send a mouse move only if it differs from the last mouse move event.

We believe this event you are seeing is a synthetic event generated from a layout that is occurring we are working at removing these. 

Continue with  Issue 161464 , we encountered this issue too. The attached is a video to show the issue (sorry we are using SCREEN2EXE, so the video format is *.exe). From the video you can see if we open in a new tab or reopen it, the issue won't happen.

I also attached our test html file. It is very simple.

This issue is not easy to recreate it as randomly. So, you might need to try more machines. Something might be helpful to recreate it: 
Looks like the chrome 55 is very easy to recreate it. But we can also recreate it in latest chrome 63.0.3239.108 (Official Build) (64-bit) sometimes. If I open chrome with incognito mode, there is a big change to recreate it in first time. 

Our OS is window 10 x64 enterprise

Thanks for your help, it is critical for some library like openlayers.

Deleted: mouseevent.exe 725 KB

mouseevent.exe 725 KB Download

Deleted: eventsCapture.html 649 bytes

eventsCapture.html 649 bytes View Download

https://jsfiddle.net/49r1zsn3/

Here is a simple jsfiddle that shows the problem.
Hold M1/M2 down and you will see the event firing even though there is no change in cursor position.

see console for output.

This reproduces sporadically in Chrome 66.0.3359.181 on macOS 10.13.4 as well. Here's a test case; clicking sometimes prints "spurious move event":

https://jsfiddle.net/tvpfkjrv/1/

I've found this bug occurs much more often if there are others tags open in the current Chrome window. Using the jsfiddle above, drag the tab into it's own window and the bug will no longer occur, snap it back with other tabs and the bug reappears.

Also found this issue is somewhat related to other tabs being open. Chrome 67.0.3396.99 on Windows 10 Enterprise 10.0.16299

Yes - this is still an issue (Chrome 69). See https://codepen.io/MSCAU/pen/mzOBpX.

I look forward to a fix.

This bug has caused problems in our lab. Multiple user reported issues I can trace to this bug.  I am now working around this issue by keeping track of x and y on mousedown and checking the values on mouseup. 

It's also visible in the last demo: https://codepen.io/MSCAU/pen/mzOBpX with below steps:
1. click and hold the button,
2. move mouse while holding,
3. release mouse and do not move it,
4. additional mousemove event fires after click, but zero movement

Win 10 / Chrome 70

Win 10 / Chome 71
Still reproduced on
http://jsfiddle.net/yzyFC/1/

Can't reproduce on lubuntu, It seems to be Windows problem indeed