Also, a mouseup event at coordinates differing from the mousedown event will cause a mousemove event misfire.

I want to document that the behavior of this has changed for me since yesterday. Hopefully anyone who plays around with my test case will be able to see that something is up. It's still pretty easy to get a misfire, but it's not misfiring for me in the same manner as before.

qdirks@ Thanks for the issue.

Tested this issue on Windows 10 on the reported version 67.0.3396.87 and the latest Canary 69.0.3465.0 by following the below steps.

1. Launched Chrome and navigated to the given html page.
2. Opened devtools -> Console and hover the mouse on the html page and clicked on the mouse button, but cannot see any mousemove event misfired logged in console.
Attached is the screen cast for reference.

Request you to check and update if anything is missed from our end in triaging the issue.

And as per Comment #3, can you please confirm what is the expected behavior of this issue?

Thanks..

Deleted: 853656.mp4 338 KB

	853656.mp4 338 KB View Download

I have attached a video to demonstrate the bug I'm experiencing. Also attached is the page I used to demonstrate. I hope this will help. I confirm that the expected behavior is that the mousemove event is triggered exclusively with mouse movements and not button presses, i.e. the throw statement should never be executed.

Deleted: chrome-bug-demo2.mp4 12.8 MB

	chrome-bug-demo2.mp4 12.8 MB View Download

Deleted: mousemove-event-misfire2.html 4.8 KB

mousemove-event-misfire2.html 4.8 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Related to number 3 on my bug behaviors list: no misfire with ctrl+tab if you are moving your mouse.

Deleted: discovered-behavior.mp4 8.1 MB

	discovered-behavior.mp4 8.1 MB View Download

I can confirm the ctrl+tab scenario but not the other one. I assume we are sending a mousemove just to let the page know that the mouse is on top of it. However, I believe we can change this behavior a little bit.
Ella, can we send that event with relativeMotionFlag on so it only sends the boundary events (i.e. mouseover/enter) and not the mousemove itself?

The fake move events for updating hovers do have the relativeMotionFlag so it shouldn't be send to dom.
For the ctrl+tab scenario, I suspect the event is coming from OS 
Windows doesn't have WM_MouseEnter event, looks like windows send an WM_Mousemove when mouse enter.
Similarly, on other OS we treat the enter event as a move event. See Mac's here: https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/web_input_event_builders_mac.mm?sq=package:chromium&g=0&l=312

I don't think there is good way to avoid sending the first move.

Lan@, WDYT?

For the ctrl_tab case, we cannot distinguish it from a real mouse move that enters a boundary. Maybe we can check the mouse coordinates with the last one to see if we should fire it. 

won't fix based on #9 and #10.