Weird behavior of compose's TextField with Mavericks

[janbina]

While playing with jetpack compose and mavericks 2.0, I encountered weird behavior of TextField. While typing, it all of a sudden duplicates the last word. I didn't find any pattern in it, but it happens 100% of the time (sooner or later). It sometimes happens while deleting characters as well, but that doesn't seem to be that common. See this video for a demonstration of both situations: https://imgur.com/a/pnEvhIq.

I don't know whether it's Mavericks fault, because the duplicated value comes directly from the onValueChange callback of TextField, but it's not happening with pure compose implementation using remember. I have no idea what's going on here.

Here is a very minimal app demonstrating this bug: https://github.com/janbina/mvrx-compose-bug/blob/master/app/src/main/java/com/janbina/myapplication/MainActivity.kt

[gpeal]

@janbina Could you try it with the latest compose alpha and the compose extensions from here?
https://gist.github.com/gpeal/5bed618a843d4d71bb1518fa8317c5df

[janbina]

@gpeal I'm sorry that it took me so long. Tried it today with compose alpha11, mavericks 2.0.0-beta3 and the extensions you linked.

The word duplication is not happening anymore, but now it does a different thing - it deletes the last word instead... And one more thing - when you have some long text in the TextField and you press and keep holding backspace to delete it, it stops after several characters as if you lift your finger from the backspace (but you didn't). Again, this is not happening if you just replace mavericks viewmodel with remember { mutableStateOf("") }.

I updated the original repo so you can try it yourself and here is a video of the word disappearing problem: https://imgur.com/a/K2MznH4.

[Namnodorel]

I have a similar problem, pretty much since I started using Mavericks with Compose. It is not a bug in Mavericks, but rather a problem that stems from the assumptions Compose makes.

Compose assumes that the ViewModel will set the new state immediately when the value change listener is called. This however creates multiple kinds of problems when that isn't the case - Mavericks sets the state asynchronously, which results in the internal state of the textfield and the actual state being out of sync. I reported an issue about the textfield cursor randomly jumping to Google a while ago (https://issuetracker.google.com/issues/160257648) and since then a new ticket has been created for potentially reworking that part of the API: https://issuetracker.google.com/issues/172239032

Unfortunately, there has been little activity on the subject recently.

[elihart]

Thanks @Namnodorel, it's really helpful to have the mechanism explained and a ticket filed with Google. Hopefully this means a solution is coming soon 🤞

[Namnodorel]

The main issue I linked previously has been closed now (and there were some changes made), but at least the bug I was experiencing hasn't been fixed yet by Compose. @janbina is the issue still present on your end?

Compose 1.0 was just released, so I'm afraid that this incompatibility is unlikely to be fixed on their side anytime soon, since it would likely require changing the Compose TextField API, which many devs will now use in production.

[litrik]

Does anybody known a workaround for this weird behavior? Even with the latest Mavericks (2.6.1) and the latest Compose (1.2.0-beta02) the TextField in unreliable.

[plume-mzukic]

This is not issue with Maverick but compose itself, read more here:
https://medium.com/androiddevelopers/effective-state-management-for-textfield-in-compose-d6e5b070fbe5
TL;DR

To prevent synchronization issues and unexpected behaviors:

• Avoid delays/asynchronous behaviors between typing and updating TextField state.

• Avoid holding TextField state using a reactive stream (e.g. collecting from StateFlow using the default dispatcher)

• Define TextField state variables with Compose APIs like MutableState.