Usually I can hold delete on my keyboard to contin...

# compose-android

[Zoltan Demant]

Usually I can hold delete on my keyboard to continue deleting characters in input fields. This is no longer the case, using M3 and a pretty basic TextField with remember & mutableStateOf("").

[Stylianos Gakis]

I know I am not helping answer your question in particular, but how does it work with the TextFieldState overload instead of passing in the String itself, does it work properly there?
Provided m3 has an overload for that of course, not sure if it has landed yet.

[Zoltan Demant]

I'm using the state one!

From some research.. the issue may be related to me tweaking the string in onTextChange, so there's a disconnect between what the ime input results in versus actual text. Will investigate when I'm back at my computer!

[Stylianos Gakis]

You mention mutableStateOf("") so I assume you are not using the state on actually, right?

I guess it depends what we mean when we say "the state one" actually 😅
I meant the overload taking in TextFieldState

[Zoltan Demant]

Ahh yes, sorry. I'm kind of using both then, in my feature I just have remember string, and then in my actual text input composable I'm updating the state based on the string. In terms of logic identical to what I did in M2 (no issues there).

[Halil Ozercan]

If you are editing the state directly, you are likely experiencing the IME reset. Basically when there is a disconnect between what IME sends to the editor and what it gets back, IME wants a inputMethodManager.restartInput call. This is mostly about the content of the text, if you end up only changing the selection, usually IME only requires inputMethodManager.updateSelection() , then it doesn't reset.

As a user, you wouldn't even notice IME reset events most of the time. But long pressing on backpress is one of those cases where you would definitely feel it.

[Halil Ozercan]

Can you please share your exact use case and what kind of changes you are making to the TextFieldState ? There are some exceptions to this rule that I just described so if an exception makes sense, we can fix it.

[Halil Ozercan]

Or you can just file a bug

[Halil Ozercan]

an exception; password input. When the keyboard is configured as password, we don't care about reseting the IME since IME doesn't really maintain a composition state or anything. It just turns into a hardware keyboard simulator

[Zoltan Demant]

Thanks for the feedback. Im pretty sure I was somehow misusing the TextFieldValue variant. Just switching to the string version solves a bunch of text selection issues that Ive been having and Ill try the deletion case later today (but almost certain that it will work too).

[Zoltan Demant]

I dont quite understand why it broke but Im assuming its related to me using mutableStateOf(string) in my "editor"; and then patching that into the TextFieldValue (just using .copy(text=newText) whereas I could just use the string overload directly like I am now. I wouldnt suggest investigating further as its probably just me doing something wrong ^^ I really appreciate the help though and Ill report back later today in regards to the text deletion.

[Zoltan Demant]

I was just reminded why I was using TextFieldValue to begin with:

Whenever I have "prefilled" text, I think its only natural for the cursor to start out at the end; this is not the case when using the string variant.

[Halil Ozercan]

I'm so confused right now. Are you using the new TextField that takes a TextFieldState parameter or the old one that takes in value and onValueChange

[Zoltan Demant]

Old one

[Zoltan Demant]

Okay, I finally had a chance to experiment more with this today .. and I have no clue how I can get it all to work together. I think the UX is terrible if the continious delete doesnt work in a searchfield 😅

Im using M3: TextField and OutlineTextField with TextFieldValue. Im doing this because I find the cursor positioning with the string overload to not match my preferences. But thats the only reason, it seems that for everything else - the string overload "just works".

I think the fact that Im using TextFieldValue while also kind of trying to use strings, is whats causing issues for me. Ive tried a multitude of different ways to update the state; the simplest being just doing textFieldValue = textFieldValue.copy(text = newText). I always store the "actual data" as string, for sake of example this could be in a ViewModel with say MutableStateFlow<State> where State.text exists and is updated whenever the input field changes.

[Zoltan Demant]

✅ !!
I ended up using BasicTextField with TextFieldValue, making sure the simplest case works; then making ever so tiny tweaks to the logic until it matched what I had in my design system.
Then moved everything over, switched to TextField/etc, and to nobodys surprise: it now works there too!

[Zoltan Demant]

Ill push this to the play store so that I can test on an actual device, I dont trust emulators 😄

[Zoltan Demant]

But if it does, seems like I can tweak the text in onValueChange, but I gotta be very careful about the cursor positioning?

[Halil Ozercan]

I'd suggest trying different software keyboards rather than focusing testing this with real devices compared to an emulator. Gboard, Swiftkey, Samsung's keyboard, they have all quite different approaches to IME composition.

[Zoltan Demant]

Ill do that! Thank you 🙂

[Zoltan Demant]

Just wanted to say thanks again, even continious delete works now! Seems like the error I made earlier was minor, I cant really find it even; but I learned that I gotta be very careful about how I tweak the input before/after passing it into input fields 🤌🏽