Allow TextBox to specify type of text being input

[frenzibyte]

Also has the bonus feature of allowing password managers (e.g. 1Password) to be integrated with the game, by specifying the text input type as Username/Password in the textboxes. Unfortunately it's still quite broken in SDL but should be fixable (see libsdl-org/SDL#11406 (comment)).

Since text input types are now identifiable with the new TextInputType field, I've applied a refactor on the TextBox classes to respect the type at a TextBox level w.r.t. certain functionalities such as clipboard exporting, key event logging, character display, etc. This includes removing BasicPasswordTextBox entirely as its behaviour can be achieved by simply:

new BasicTextBox
{
    InputProperties = new TextInputProperties(TextInputType.Password, allowIme: false)
}

I've gone for this refactor as it didn't sit well for me how these implementations still exist while there is now a new field specifying the type of text input.

[bdach]

Compilation failures here

[frenzibyte]

Noticed, fixed.

[smoogipoo]

I think this looks okay.

I'm not sure about IME being a property you have to set as opposed to being optional defaulting to true, or maybe even null and a sane default chosen per type (IME doesn't make sense for numbers/passwords, but maybe this is blocked at and SDL level?).

[bdach]

What does this actually... suppress? Because in debug, when I run the game, and type into a password text box, key events are still logged. And that's because they're being logged in a completely different location, namely

osu-framework/osu.Framework/Input/ButtonEventManager.cs

Lines 135 to 136 in d4d9cca

	if (handledBy != null)
	Logger.Log($"{e} handled by {handledBy}.", LoggingTarget.Runtime, LogLevel.Debug);

So does this really do anything? Or did it just break at some point and nobody noticed?

[frenzibyte]

Seems like it did regress, since key input used to be logged in this location until it was moved to KeyEventManager. I'll correct it in this PR.

[bdach]

This doesn't appear to work correctly on android. When switching from a normal textbox to a password textbox immediately, IME remains available. Conversely, when switching from a password textbox to a normal textbox immediately, IME remains unavailable.

Record_2024-11-08-11-57-01.mp4

I wonder what this looks like on iOS. (I own an iOS device now, but no mac, so I still can't check myself.)

Whether this is an SDL bug, or ours, is up for debate I guess. I can say that the naive solution, i.e.

diff --git a/osu.Framework/Input/SDLWindowTextInput.cs b/osu.Framework/Input/SDLWindowTextInput.cs
index 79fa1d848..c67bf7f77 100644
--- a/osu.Framework/Input/SDLWindowTextInput.cs
+++ b/osu.Framework/Input/SDLWindowTextInput.cs
@@ -10,6 +10,8 @@ internal class SDLWindowTextInput : TextInputSource
     {
         private readonly ISDLWindow window;
 
+        private TextInputProperties? startedInputProperties;
+
         public SDLWindowTextInput(ISDLWindow window)
         {
             this.window = window;
@@ -42,10 +44,14 @@ protected override void ActivateTextInput(TextInputProperties properties)
             window.TextInput += handleTextInput;
             window.TextEditing += handleTextEditing;
             window.StartTextInput(properties);
+            startedInputProperties = properties;
         }
 
         protected override void EnsureTextInputActivated(TextInputProperties properties)
         {
+            if (startedInputProperties != null && startedInputProperties != properties)
+                window.StopTextInput();
+
             window.StartTextInput(properties);
         }
 
@@ -54,6 +60,7 @@ protected override void DeactivateTextInput()
             window.TextInput -= handleTextInput;
             window.TextEditing -= handleTextEditing;
             window.StopTextInput();
+            startedInputProperties = null;
         }
 
         public override void SetImeRectangle(RectangleF rectangle)

does not appear to help.

[frenzibyte]

I'm seeing roughly the same issue on iOS, I will have to look into libsdl-org/SDL#11406 (comment) again first to tell whether this is an issue on SDL's side or ours. Not sure about Android though, someone else will have to investigate this (libsdl-org/SDL#11406 (comment) may be relevant).

[frenzibyte]

After further investigation on the iOS issue, SDL doesn't handle updating text input properties appropriately on iOS, regardless of whether text input is active or not. I've fixed this in the PR linked above (libsdl-org/SDL@f4d81f2) for now.

[bdach]

...so i guess at this point it's either up to me to fix android in sdl, or to accept it's broken over there?

i feel like my android devices might mysteriously stop working soon.

[Susko3]

I can try to take a stab at fixing this in SDL. On first glance, it doesn't seem to be an android-specific issue as SDL will ignore requests to show the keyboard if it's already active.

[Susko3]

Created a PR, but I'm not expecting it to go in soon.

• Fix SDL_StartTextInputWithProperties not updating input type on android libsdl-org/SDL#11448

[Susko3]

ResetIme() still calls SDL_StartTextInput() without properties.

[frenzibyte]

@peppy fwiw with this PR in addition to libsdl-org/SDL#11699, users will be able to auto-fill their account passwords from a password manager with ease.

EDIT: Ok maybe still broken somewhat, need more braincells.

[smoogipoo]

Code-wise this looks fine to me and I've done a basic test (macOS).

[bdach]

Code seems ok I guess.

On the setups that I have:

• Windows works.
• I haven't tested android but I presume it's still broken because the sdl PR linked above is dead in drafts.
• On ubuntu linux x11 this doesn't do anything because IME is still available on password boxes.
• On ubuntu linux wayland this doesn't do anything because IME just straight up doesn't seem to work even after switching the keyboard language. Not a regression, already broken on master.

So if you're fine with these results I guess you can merge 🤷 I don't really care about android or linux anymore, and chances are high none of the issues are something we can fix (should be fixing?) ourselves.

[bdach]

see above i guess

[Susko3]

Let's get this in. Android is bugged, but it's not so bad. The user may end up in the wrong mode, but typing always works. And if they need an IME, they'll probably figure out that closing and opening the keyboard works around the issue. It's the classic turn it off and on again.