Fix mouse state persists on display server after app loses focus

[Naputt1]

fix for window, x11 and wayland

example of issue

1. Press left mouse to start selection
2. Alt Tab out of editor while still holding mouse button
3. Release left mouse button outside editor window
4. Right click in 3D editor while window is still unfocused

[bruvzg]

See #92419 (comment)

[Riteo]

Thank you for your contribution!

The concern above makes sense. I think too that it would make more sense to fetch the current pointer data whenever possible.

Not sure about Wayland, as there's no direct querying logic. Thing is, we do indeed receive down events even when outside the window, so I'm not really sure what's going on. I wonder if there's some filtering depending on the focus status of the window.

[Riteo]

FTR, this issue got stuck in my head for the last few days and, after a bunch of thinking and experimenting, here's what I found out.

After some tweaks to the Wayland backend, which also accidentally focus filtered some events, I can confirm that at least there pointer events are received fine. Yet, they still get blocked, for UI elements, by this:

godot/scene/main/viewport.cpp

Lines 654 to 664 in 8bf8f41

	case NOTIFICATION_WM_WINDOW_FOCUS_OUT: {
	_gui_cancel_tooltip();
	_drop_physics_mouseover();
	if (gui.mouse_focus && !gui.forced_mouse_focus) {
	_drop_mouse_focus();
	}
	// When the window focus changes, we want to end mouse_focus, but
	// not the mouse_over. Note: The OS will trigger a separate mouse
	// exit event if the change in focus results in the mouse exiting
	// the window.
	} break;

_drop_mouse_focus unsets gui.mouse_focus, which triggers an early exit in the _gui_input logic:

godot/scene/main/viewport.cpp

Lines 1807 to 1810 in 8bf8f41

	if (!gui.mouse_focus) {
	// Release event is only sent if a mouse focus (previously pressed button) exists.
	return;
	}

I think that this is the real issue and the part that requires a proper fix (supposing that other platforms don't also fail to report a button down).

Temporarily commenting out _drop_mouse_focus from the first snippet indeed fixes this issue. That said, this is clearly not the right fix.

Perhaps we could set gui.forced_mouse_motion while freelooking, or perhaps we should switch to mouse_over for filtering _gui_inputs? I have no idea what would the side effects of both methods be as I didn't have yet enough time to investigate further.

I wonder if we there's an issue ticket and if we should make one to investigate further.