This const doesn't seem to be used anywhere - can it be removed from popup_menu.h? It also shows up in option_button.h.

	// ATTENTION: This is used by the POT generator's scene parser. If the number of properties returned by `_get_items()` ever changes,
	// this value should be updated to reflect the new size.
	static const int ITEM_PROPERTY_SIZE = 10;

Doesn't seem to fix the issue

It can be fixed by storing the next submenu that should show and once the timer timeouts we show it here after we hide the previous submenu.

void PopupMenu::_minimum_lifetime_timeout() {
	close_allowed = true;
	// If the mouse still isn't in this popup after timer expires, close.
	if (!activated_by_keyboard && !get_visible_rect().has_point(get_mouse_position())) {
		_close_pressed();
	}
}

Or by having smaller wait time for both timers, I have tried 0.01 and it's more user friendly than 0.3.

	submenu_timer = memnew(Timer);
	submenu_timer->set_wait_time(0.3);
	submenu_timer->set_one_shot(true);
	submenu_timer->connect("timeout", callable_mp(this, &PopupMenu::_submenu_timeout));
	add_child(submenu_timer, false, INTERNAL_MODE_FRONT);

	minimum_lifetime_timer = memnew(Timer);
	minimum_lifetime_timer->set_wait_time(0.3);
	minimum_lifetime_timer->set_one_shot(true);
	minimum_lifetime_timer->connect("timeout", callable_mp(this, &PopupMenu::_minimum_lifetime_timeout));
	add_child(minimum_lifetime_timer, false, INTERNAL_MODE_FRONT);

Edit: minimum_lifetime_timer is the issue, but submenu_timer can be changed to 0.1 instead of 0.01 to avoid showing it while moving the mouse over the items fast.

Also this may be related to why the popup menu didn't receive the motion event when the mouse entered.

• CollisionObject2D's input_event signal emits inconsistently when subwindows are created #110093

Doesn't seem to fix the issue

The whack-a-mole continues - thanks for finding that. If you set the submenu timer to 0.1 does it still act the same per @WhalesState?

Is there a movement sequence you can replicate this on an Editor menu? I will set this up for myself and go back on the hunt.

Edit: minimum_lifetime_timer is the issue, but submenu_timer can be changed to 0.1 instead of 0.01 to avoid showing it while moving the mouse over the items fast.

I agree that 0.1 feels better - any reason we can't set the default to 0.1 instead of 0.3?

thanks for finding that

I just tested with the MRP from the issue you linked 🙃

If you set the submenu timer to 0.1 does it still act the same

Yes.

I just tested with the MRP from the issue you linked 🙃

That's pretty funny! My notoriety must be in reinventing the wheel. I've been testing with a much fancier menu that doesn't exhibit the issues as obviously for an as yet unknown reason.

I just tested with the MRP from the issue you linked 🙃

Okay, go to project settings and disable embed_subwindows and everything works perfectly. I should have tested this properly with embedded subwindows. This might indeed be related to something like #110093.

Also this may be related to why the popup menu didn't receive the motion event when the mouse entered.

There seems to be an issue regarding incorrect determination of the mouse leaving the safe area.

There seems to be an issue regarding incorrect determination of the mouse leaving the safe area.

Yes, The issue is that the parent window only process one event while another window has focus, but when you disable embedding sub-windows they become just fake windows extending Control node so the mouse events works fine.

Okay, go to project settings and disable embed_subwindows and everything works perfectly. I should have tested this properly with embedded subwindows. This might indeed be related to something like #110093.

Also this issue is in both embedded and non-embedded windows so maybe you forgot to revert back the timer changes while testing or you test with the changes from this PR, i have tested with editor submenus in master and the issue also exists there by default and the editor is not embedding subwindows.

Also check what happens here, the root window receives one mouse event when another window is focused but when you focus it no other window receives any input, the settings window is exclusive so the parent window shouldn't receive any input at all.

i have tested with editor submenus in master and the issue also exists there by default and the editor is not embedding subwindows.

The PR fixed the issue with non-embedded windows and the Editor, though I found a couple of bugs there that I'm taking care of. What I've got working now for embedded widows is to emit the popup_hide signal when a submenu closes, which then creates an InputEventMouseMotion event that forces the parent menu to process a mouse movement over the currently hovered item. This seems to offer a solution for the time being. I will set the default submenu wait time to 0.1 and we can test it out to see if it's satisfactory. I think the ergonomics are better with the faster response.

What you demonstrated regarded no window receiving input, might certainly be related to the closed submenu blocking input to the parent menu, which is the source of the blocked submenu issue. This is a deeper problem with Window - fixing that might also take care of the "hung" activation of submenus that requires that callable loop to fix.

After a lot of frustration, I finally had to get rid of the minimum_lifetime_timer as it was the source of many of the issues. I replaced it with close_suspended_timer, which is only set in the parent menu, whereas minimum_lifetime_timer was being set in each submenu. The code now enforces submenus only being activated after any open submenus are closed. This eliminated the need for the hack double-calling _activate_submenu(), which I believe was being caused by a race condition where a prior submenu was in a closing state while the next was being activated.

The other major problem was the fixes for issues with embedded vs. non-embedded subwindows were completely different. The only way to get embedded subwindows to work was connecting popup_hide to spoof a mouse input on the hovered menu item that's triggered by the submenu closing.

When the mouse moves out of a submenu item, it's last relative motion state inside its menu item is preserved, and if it's moving into the lower right quadrant (or lower left if right-to-left layout), it will start the close_suspended_timer which runs for 0.5 seconds to allow the mouse to sweep into the open submenu across other menu items without triggering them to open or close the open submenu. This timing is modeled after the behavior of MacOS system menus, which seems reasonable.

Finally, I reduced the default submenu delay time from 0.3 to 0.1 seconds, as that feels more natural and responsive, and the fixes above make it unnecessary to prolong the opening of the submenu.

This push adds support for right-to-left layouts for the direction testing of mouse movements toward an open submenu.

One final recommendation, however: I think this behavior of the cursor's arc deciding if the submenu stays open or not should be documented somewhere.

@YeldhamDev Are you thinking in the class doc? I suppose it could go with submenu_timer_popup_delay?

Yeah, that sounds like a good place.

This push includes all suggested changes.

I worked out a fix for this very pesky flickering issue, but ran into another DisplayServer bug that's thwarting wrapping this up. See #112620.

This push fixes the flickering issue and ensures proper function with per_pixel_transparency and content_scale_factor settings. Lots of work.

I also fixed a tricky bug that intermittently caused a submenu to close unexpectedly while moving the mouse toward it. This was caused by an unpredictable delay between when a timer is started and when is_stopped will return a valid result. This can unexpectedly be longer than 30 msecs. The result makes the mouse direction detection really reliable and the menu performance feels solid.

Everything seems to be functioning properly for both embedded and non-embedded windows, so give it a whirl.

Final push. Also nabbed the last source of the occasional error message.

Thanks!

Yahoo!

This PR broke popup menus on Windows in editor, Was this PR tested on Windows at all before merging??
Recently, each update seems to introduce new regressions.
On Windows simply hovering a pop up menu such as Project > Tools triggers this error :

ERR_FAIL_COND_MSG(submenu_popup->is_visible(), vformat("_activate_submenu should not be called on an open submenu - index: %d.", p_over));

The error message does not necessarily indicate any instability, but I'll see about tracking down what's happening. How are the popups working otherwise? Is there any sequence of movement that repeatably triggers the error message?

The error message does not necessarily indicate any instability, but I'll see about tracking down what's happening. How are the popups working otherwise? Is there any sequence of movement that repeatably triggers the error message?

Simply hovering on the popup menus in editor triggers the error, I cloned current upstream and built it without any changes. I'm on Windows 10 x64...

Replacing back the error block with

	if (submenu_popup->is_visible()) {
		return; // Already visible.
	}

Will fix it but I'm not sure if that's good.

Are you using single-window mode or default?

I can't replicate this on Win 10 at the moment, but since I believe it is being handled cleaning by the return I can look at reducing the error spam here and in a few other places. Is anyone else observing this error?

I also have a fix ready for error messages releated to global and native system menus.

I managed to replicate it once (in multi window mode). Seems like rather random error.

My best guess at the moment is there is a random and short delay between the submenu hiding and when submenu_popup->is_visible returns false. I think it's safe not to show the error.

Should be fixed by #112967