Inconsistent keyboard event handling when both login and settings are open

[audeck]

Type

Game behaviour

Bug description

If you open the login menu (widget?) while logged out (i.e. there are inputs in the menu), then open the settings drawer using the Ctrl+O shortcut, you can type into the settings search input, but events such as Backspace, Ctrl+A have no effect on the input.

It seems like some events are still being handled by the login menu, as it's still the top-most component (i.e. pressing Escape closes it, rather than the settings drawer, even if the latter was open later), but some (such as typing) aren't. This obviously feels unintuitive.

Screenshots or videos

No response

Version

2024.906.2-lazer

Logs

compressed-logs.zip

[audeck]

On a different note; good first issue?

[bdach]

On a different note; good first issue?

Upon investigation - clearly not.

I don't have the full picture here, but there seems to be a difference in the input queue as created for the handling of text input, and the input queue used for everything else. While normal text input reaches the textbox, platform actions get blocked by this OverlayContainer logic - while traversing the drawable tree, the SettingsOverlay happens to be entered first, and the LoginOverlay second, which means that the aforementioned logic as fired by LoginOverlay nukes the settings search box from the input queue.

There are a few viable one-liner fixes here, such as

diff --git a/osu.Game/Overlays/LoginOverlay.cs b/osu.Game/Overlays/LoginOverlay.cs
index d570983f98..e62cabff17 100644
--- a/osu.Game/Overlays/LoginOverlay.cs
+++ b/osu.Game/Overlays/LoginOverlay.cs
@@ -25,6 +25,8 @@ public partial class LoginOverlay : OsuFocusedOverlayContainer
         [Cached]
         private OverlayColourProvider colourProvider = new OverlayColourProvider(OverlayColourScheme.Purple);
 
+        protected override bool BlockNonPositionalInput => false;
+
         public LoginOverlay()
         {
             AutoSizeAxes = Axes.Both;

or

diff --git a/osu.Game/Overlays/SettingsSearchTextBox.cs b/osu.Game/Overlays/SettingsSearchTextBox.cs
index 84cff1b508..d533cbbe7c 100644
--- a/osu.Game/Overlays/SettingsSearchTextBox.cs
+++ b/osu.Game/Overlays/SettingsSearchTextBox.cs
@@ -2,12 +2,13 @@
 // See the LICENCE file in the repository root for full licence text.
 
 #nullable disable
+using osu.Framework.Input;
 using osu.Framework.Input.Events;
 using osu.Game.Graphics.UserInterface;
 
 namespace osu.Game.Overlays
 {
-    public partial class SettingsSearchTextBox : SeekLimitedSearchTextBox
+    public partial class SettingsSearchTextBox : SeekLimitedSearchTextBox, IHandleGlobalKeyboardInput
     {
         protected override void OnFocus(FocusEvent e)
         {

or maybe something else entirely to disallow this situation from ever happening? @ppy/team-client any thoughts?

[Susko3]

The settings overlay is behind the login overlay. Visually, and by click-outside-to-close priority.

The real issue is that the settings text box gets focus when opened behind the login overlay. This issue can be avoided by closing the login overlay when settings are opened. Same as the beatmap listing & chat overlays close settings.

The same issue is with opening now playing, and then the login overlay (the password text box you don't see is focused and can't receive keyboard shortcuts).

[bdach]

This issue can be avoided by closing the login overlay when settings are opened

Well, obviously it can, except I imagine the login overlay being able to non-intrusively be present is the point. As in, you would want to be able to open login overlay without closing settings simultaneously.

[Susko3]

Well, obviously it can, except I imagine the login overlay being able to non-intrusively be present is the point.

It's currently intrusive if you have the login overlay open and then open settings. The first click on settings will close the login, preventing immediate interaction.

As in, you would want to be able to open login overlay without closing settings simultaneously.

Yep, see how the aforementioned settings and beatmap listing interact.

[bdach]

So you're proposing to have settings overlay close login overlay, but login overlay not close settings overlay? I... am not sure I can get behind that. That's weird to me. These types of interactions should be symmetrical.