-
Notifications
You must be signed in to change notification settings - Fork 436
Fix menu items being clickable during fade out #6563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Addresses concerns cited in ppy/osu#32735.
public override bool PropagatePositionalInputSubTree => State == MenuState.Open; | ||
public override bool HandlePositionalInput => State == MenuState.Open; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While setting these will indeed prevent the other menu items from being clicked, it will also allow mouse input to fall through the context menu to whatever is behind it.
In the test you modified here, that can be exercised by
diff --git a/osu.Framework.Tests/Visual/UserInterface/TestSceneClosableMenu.cs b/osu.Framework.Tests/Visual/UserInterface/TestSceneClosableMenu.cs
index 9d7959e8b..33657ab3a 100644
--- a/osu.Framework.Tests/Visual/UserInterface/TestSceneClosableMenu.cs
+++ b/osu.Framework.Tests/Visual/UserInterface/TestSceneClosableMenu.cs
@@ -131,6 +131,7 @@ public void TestItemsNotClickableDuringFadeOut()
bool item1Clicked = false;
bool item2Clicked = false;
bool topLevelItemClicked = false;
+ bool backgroundClickReceived = false;
AddStep("set item actions", () =>
{
@@ -138,15 +139,23 @@ public void TestItemsNotClickableDuringFadeOut()
Menus.GetSubMenu(0).Items[0].Items[1].Action.Value = () => item2Clicked = true;
Menus.GetSubMenu(0).Items[1].Action.Value = () => topLevelItemClicked = true;
});
+ AddStep("add mouse handler", () => Add(new MouseHandlingLayer
+ {
+ Action = () => backgroundClickReceived = true,
+ Depth = 1,
+ }));
AddStep("click item", () => ClickItem(0, 0));
AddStep("click item", () => ClickItem(1, 0));
AddAssert("menu item 1 activated", () => item1Clicked);
+
AddStep("click item", () => ClickItem(1, 1));
AddAssert("menu item 2 not activated", () => !item2Clicked);
+ AddAssert("background did not receive click", () => !backgroundClickReceived);
AddStep("click top level item", () => ClickItem(0, 1));
AddAssert("top level item not activated", () => !topLevelItemClicked);
+ AddAssert("background did not receive click", () => !backgroundClickReceived);
}
private partial class MouseHandlingLayer : Drawable
Do you see this as a problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't. At the point the menu is "closed", we can assume it's transitioning away from existence. From a user's perspective, they should be able to interact behind it (else they will have to learn that their clicks may be blocked for n milliseconds after dismissing a menu).
So I'd argue what is in this PR is more correct than trying to block during that duration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we shall see what "hilarious" input handling issues, if any, shall come of this
FWIW i already ran all osu tests against this change. |
Addresses concerns cited in ppy/osu#32735.