PopupMenu does not highlight items on mouse over if a submenu is opened

[Tetane]

Godot version

v4.0.beta.custom_build [2a04b18] (also present in the v4.0 official beta build)

System information

Windows 10

Issue description

PopupMenu does not highlight items on mouse over if a submenu is opened:

For comparison, here is an example of a popup menu in vscode to show how it should behave (items are highlighted even if the submenu is opened):

Steps to reproduce

Open a PopupMenu and a submenu in the editor, and mouse over items in the popup_menu while the submenu is opened.

Minimal reproduction project

Any project.

[EricEzaM]

I think what's happens is The viewport of the submenu gets window focus when it opens, so mouse move events are not received by the unfocused viewport (parent menu).

[Maran23]

I think what's happens is The viewport of the submenu gets window focus when it opens, so mouse move events are not received by the unfocused viewport (parent menu).

Can confirm this from my testing. Although the popup_menu gets mousevents, the InputEventMouseMotion coordinates are based on the submenu (e.g. x coordinate is negative), therefore the logic can not detect any mouse hover.

[MinusKube]

I think this bug occurs since this change (from #67903):

godot/platform/windows/display_server_windows.cpp

Lines 3067 to 3073 in 63b5adf

	DisplayServer::WindowID receiving_window_id = _get_focused_window_or_popup();
	if (receiving_window_id == INVALID_WINDOW_ID) {
	receiving_window_id = window_id;
	}
	Ref<InputEventMouseMotion> mm;
	mm.instantiate();
	mm->set_window_id(receiving_window_id);

Is there a reason for calling the event on the focused window instead of window_id (the window for which WndProc was called)?

[akien-mga]

CC @Sauermann @bruvzg

[Sauermann]

Is there a reason for calling the event on the focused window instead of the window for which WndProc was called?

This change was necessary so that DisplayServerWindows and DisplayServerX11 behave in the same way.
Changing the event-receiver here, would make it necessary to adjust the behavior in X11 too.

[MinusKube]

Does this bug occur with X11?

[Sauermann]

I can't replicate this bug on X11 Xfce with v4.0.beta.custom_build [a43db5a]

[gitcatrat]

Was about to open an issue about this..

Godot is only running on my old-ish Windows 10 PC, haven't tried on any other device or OS.

Godot Engine v4.0.rc1.mono.official.8843d9ad3 - https://godotengine.org
Vulkan API 1.2.170 - Forward+ - Using Vulkan Device #0: AMD - AMD Radeon R9 200 Series

Can replicate it everywhere: on editor menus and in-game menus for both dev run and exported build.

Only happens when sub-menu is opened, if it stays closed, then everything is smooth, even submenu list item hover. So the focus seems like a plausible cause, a test to confirm focus: if submenu opens, then letter key search searches only submenu.

Setting the opening delay won't have any effect, as long as submenu opens then discussed bugs happens.

[gitcatrat]

Adding just in case it clears something up: setting menu.GuiEmbedSubwindows to true does get rid of the input lag issue.
A warning to anyone rushing to implement it as a fix: it's probably not what you want, submenu positioning changes.

[Tetane]

I also had the issue with tooltips in a menu, it could be related to the original issue.
When the tooltip appears, it grabs the focus and only disappear if I click somewhere else.

[akien-mga]

Tested on Linux, KDE Wayland with current 4.3.dev (0246230).

I can reproduce the issue in single window mode with both Wayland and X11.
I don't reproduce the issue with X11 in multi-window mode (not supported to test on Wayland).

I see no change from #88392 on Linux. I assume #88392 might be fixing the Windows multi-window issue, and may not fix it for single-window on Windows either? @bruvzg