Fix for Windows OS Incorrect Mousemove Event (fix: #10721)

[cyfung1031]

fix #10721

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch (or v[X] branch)
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on a Electron app
• Any necessary documentation has been added or updated in the docs (for faster update click on "Suggest an edit on GitHub" at bottom of page) or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

// windows OS's bug for mousemove event (Blink Engine - Edge & Chrome, Windows Only)
// mousemove event occurs even there is no movement after mousedown
// https://bugs.chromium.org/p/chromium/issues/detail?id=161464
// https://bugs.chromium.org/p/chromium/issues/detail?id=721341
// #10721

[pdanpdan]

Hello. The problem is not in VTouchPan (it works as expected) but in its usage in some components.
If you want and have time try to migrate the fix (done in v1) to v2 - pdanpdan@8cdd294

[rstoenescu]

@pdanpdan The usage should not matter. The developer having to do some gymnastics with the first/last event is not something we should enforce. This should be fixed within the touch directives in any way possible.

[pdanpdan]

There is no way to fix it. When the detection is forced the first event can also be the last event.

[rstoenescu]

So the touch directive can emit two events. A "first" and a "last". The logic within the devland handler should not be enforced in any way.

[rstoenescu]

Took a closer look. The approach in the PR seems right because in this particular scenario TouchPan will not emit anything (not even the start) as if no move was registered.

@cyfung1031 Thanks for contributing! Pushed another commit on top of this one to polish some things.

This PR will go into Quasar v2.1.4.