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]

My question here would be why this is not

Suggested change

	ScheduleCommand(() => Imm.SetImeAllowed(WindowHandle, properties.AllowIme));
	ScheduleCommand(() => Imm.SetImeAllowed(WindowHandle, properties.AllowIme && !properties.Type.IsPassword()));

or similar (same for SDL2 pathway). Seems like it'd be a sane default?

Incidentally I'm not even sure why we still have this windows specific code. Why is it not all delegated to SDL? @Susko3 can you shine a light on that?

[frenzibyte]

Made AllowIme default and added an auxiliary check to disable IME where not supported.

[Susko3]

@bdach When I first tested the SDL2 implementation of text editing events, it wasn't working as expected on windows. Doing a quick test of the SDL3 impl, it seems to work just fine. I'll do a bit more testing and make a PR changing SDL3WindowsWindow to use the SDL impl on windows.

[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.