Fix Android composer cursor bug by removing setTimeout
from native composer onChangeText
#4922
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
Fixes #2703
It seems that we were using a
setTimeout()
hack in theonChangeText
handler. This appears to have been previously necessary back in@mattermost/react-native-paste-input@0.6.0
, and there were quite a few issues and "fixes" that came out of it. See #929 which added thissetTimeout()
.However, this timeout is actually causing problems on Android when composing posts. The cursor will frequently "move back" a space whenever the user is typing fast. After removing this timeout, I can't repro the behavior anymore. I also cannot reproduce the behavior that's noted about the wrong elements being painted. Maybe @estrattonbailey has more context on something I might be missing.
Admittedly, there isn't anything that screams "this is the fix!" (see https://github.com/mattermost/react-native-paste-input/releases, the releases are mostly just dependency bumps), though it is also worth noting that this library essentially just subclasses React Native's text components on either device, so it's maybe possible that there was a fix upstream for whatever the problem was. Or, we might have fixed something along the way that fixes this problem (i.e. the autocorrect bug we had for a long time and fixed in a patch).
Again though, maybe I'm missing context/don't know how to repro this problem.
Test Plan
Screen.Recording.2024-08-11.at.10.31.16.PM.mov