PopupMenu ignores mouse hover to adjacent item after sub menu opened until jiggled

[Koyper]

Godot version

4.1dev (6d7413b)

System information

MacOS M1

Issue description

Moving the mouse from a PopupMenu open sub menu item to another sub menu item is ignored until the mouse is jiggled. This is probably related to #70361

Inhibiting the minimum_lifetime_timer in popup_menu.cpp (effectively setting the timeout to zero) seems to mostly eliminate the issue. Keyboard navigation still works as expected, so I would propose getting rid of the lifetime timer completely.

I am wondering why there is a sub menu lifetime timer at all, because the sub menu should close instantly as soon as the mouse moves to another item. For example, this is how at least MacOS behaves. Is there a rational for the lifetime timer I'm not considering?

Screen.Recording.2023-05-19.at.10.27.32.AM.mov

Steps to reproduce

See MRP below.

Minimal reproduction project

popup_issues.zip

[timpt0261]

I'm gonna take this problem, as it my first time in working with open-source

[Calinou]

I am wondering why there is a sub menu lifetime timer at all, because the sub menu should close instantly as soon as the mouse moves to another item. For example, this is how at least MacOS behaves. Is there a rational for the lifetime timer I'm not considering?

• See Added hysteresis for popup sub-menus #41851.

I'm gonna take this problem, as it my first time in working with open-source

Did you make any progress? If you don't know where to look, let us know 🙂

[Koyper]

I'm gonna take this problem, as it my first time in working with open-source

Welcome aboard! Thank you for offering to contribute.

Here are a few ideas that you can take or leave at your discretion:

I see now where that lifetime timer came from, and it seems to be part of the problem. I had discovered the need for it by setting its duration to zero - when you go after a sub menu item that's at the middle or lower of the list, your mouse might just touch the next item and close the sub menu before reaching it. I experimented with the timing and it works better at a much shorter duration - around 0.03 seconds. It only needs to last as long as the mouse is sweeping across the corner of the next item.

Here's an even better possible approach. Even though the hysteresis PR above didn't think factoring in mouse relative movement was needed, I think it can be done fairly easily.

Here's a short script you can run that will test whether the mouse is moving generally downward, or generally to the right:

extends Control

var ur_quadrant := Vector2(1, 0.7).normalized()

func _gui_input(event):
	if event is InputEventMouseMotion:
		var motion_vector: Vector2 = event.relative
		if ur_quadrant.dot(motion_vector * Vector2(1, -1).normalized()) < 0:
			prints("Moving down")
		else:
			prints("Moving right")

This can be ported to cpp easily as all the methods are available there too. InputEventMouseMotion is already being handled so you can set a bool there.

Now, if the mouse is moving generally down, do not start the lifetime timer, if it's moving generally right, start the timer, but try shortening the duration to something like 0.03-0.06.

[akien-mga]

Tested on Linux, KDE Wayland. I can confirm results similar to the ones described by @Sauermann in #88392.

In 4.3.dev (0246230):

• With X11 multi-window mode (configured in project settings for the MRP), I don't reproduce the bug.
• With single-window mode / embedded subwindows under both X11 and Wayland, I reproduce the bug.

#88392 doesn't seem to change that status quo for either scenario.

[TX256]

This seems to still be an issue in 4.3 stable - 4.4 dev 6.

In single-window mode, I need to move the mouse slightly to open the sub-menu at all.

In multi-window mode, I don't need to move mouse, but there's a slightly ugly delay until the item gets focus at all - and after that the sub-menu is opened.

I'm on Windows 11.