This isn't a rogue event. It is sent part of the long press sequence for interoperability. You are seeing the event after 680ms because of the long press gesture timer. 

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/GestureManager.cpp?l=371

Do you have a specific use case where this is misbehaving?

I have this little project where we render game controllers on Android and send WebRTC events from user input: http://snex.io/

The code is written to handle both mouse and touch gestures. The problem I got with this "bug" was that when the mousemove event is fired, no buttons are considered pressed, and I read that as user has stopped all input. That code can be found here: https://github.com/snex-io/snex-web/blob/9fce49da766c4f2e42d92eeded3de3a0ddc0dbe6/public/scripts/remote.js#L74

I can certainly handle this by any number of circumventions in JavaScript, but to me it looks like a code design smell that a mousemove event has to be fake emitted on a touch device. However, I don't know enough about the history around that decision to say.

Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

There are lots of fake mouse moves emitted on touch devices for compatibility issues.

I suggest you actually write your app using pointer events instead of handling the legacy touch and mouse events.

Although it depends on the target of your application because iOS doesn't support pointer events.

The NextAction date has arrived: 2017-05-22