Tooltips may fail to display due to spurious zero-motion WM_MOUSEMOVE events on Windows

[jadoc]

Tested versions

Reproduced in 4.1, 4.2, 4.3, and 4.4 builds from master branch.

System information

Windows 10.0.22631

Issue description

Before displaying a tooltip, Godot sets a SceneTreeTimer and waits for gui/timers/tooltip_delay_sec before showing the tooltip. Any received InputEventMouseMotion event resets this timer. On Windows, Godot translates every OS level WM_MOUSEMOVE event into a an internal InputEventMouseMotion event.

On Windows, WM_MOUSEMOVE is not guaranteed to only fire from mouse motion. For example, it may be generated as part of WM_NCHITTEST events from other applications. In my case, the application ElevenClock will generate a constant stream of WM_NCHITTEST and WM_MOUSEMOVE events to other applications. In the case of Godot, this will prevent tooltips from ever appearing. Winamp is also known to have this behavior.

Here's a Chromium bug from 2014 that similarly discovered and had to deal with spurious WM_MOUSEMOVE events on Windows: https://issues.chromium.org/issues/41118169

Additionally, Godot itself will generate InputEventMouseMotion without any actual mouse motion on any operating system, such as when the cursor changes shape. It's simply not safe to assume that InputEventMouseMotion means that the mouse has moved without inspecting relative position.

The timer should only be reset when the relative position is non-zero. The documentation for InputEventMouseMotion should also probably be updated to note this caveat.

Steps to reproduce

Reliable reproduction requires running the editor with other software that's known to regularly run hit tests against other windows, such as ElevenClock. When running the Godot editor next to such an application, tooltips will be broken throughout the editor regardless of the current project.

Minimal reproduction project (MRP)

N/A

[jadoc]

I have proposed #95846 as the fix.