TextInput desynchronizes with its native counterpart #37722

Activity

1. jakub-trzebiatowski

   added

   Needs: Triage 🔍

   on Jun 6, 2023
2. github-actions commented on Jun 6, 2023

   

   github-actionsBot

   on Jun 6, 2023

   More actions

   ⚠️

   Newer Version of React Native is Available!

   ℹ️

   You are on a supported minor version, but it looks like there's a newer patch available - 0.71.8. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.
3. github-actions

   added

   Newer Patch Available

   Component: TextInputRelated to the TextInput component.Related to the TextInput component.

   on Jun 6, 2023
4. jakub-trzebiatowski commented on Jun 6, 2023

   

   jakub-trzebiatowski

   on Jun 6, 2023

   ContributorAuthor

   More actions

   Also reproducible on 0.71.8. I pushed the new revision of the MCVE with all dependencies upgraded to their newest versions.
5. cortinico

   added

   Issue: Author Provided ReproThis issue can be reproduced in Snack or an attached project.This issue can be reproduced in Snack or an attached project.

   on Jun 6, 2023
6. hannojg commented on Jul 2, 2024

   

   hannojg

   on Jul 2, 2024

   Contributor

   More actions

   I've worked on this issue and found multiple possible solutions, but only one that really seems to make sense.

   🔎 The problem

   Imagine the following flow:

   • Spam the 'a' key, typing 'aaaaaa...'
   • Press a button that clears the input (ie. setting value to "", or calling .clear() [both do the same under the hood])
   • Spam the 'b' key, typing 'bbbbbb...'
   • You'd expect that the input first shows 'aaaaaa', then clears it, then it shows 'bbbbbb'. This works in most cases, but there is a race condition as this bug reports:

   In react native the text input sends the whole text that's currently in the text input in the onChange/onChangeText event callbacks. However, we maintain the "source of truth" for our text input in JavaScript in our react state variable value which we pass as a prop to the <TextInput value={value} />.

   So it can happen that we set our JS value to "" to clear the input, but the native side is ignoring that event (as the JS thread is lagging behind in events), and sends us instead a new update with the current native input, which would be "aaaaaabbbbbb" by then.

   Solution 🅰: make .clear() a separate view command that bypasses the event count mechanism

   When calling textInputRef.current.clear() we currently issue a view command called setTextAndSelection("", 0, 0, mostRecentEventCount), which is basically the same as apssing the prop value={""}, as this would also call the setTextAndSelection view command.

   We could add a new view command clear() that bypasses the event count mechanism and just clears the native text input.

   This would basically mean that we will never ignore an explicit clear event.

   ⚠️ Problems

   Lets assume the flow from above, here is what the user would see:

   • "aaaaaa"
   • (press on clear button)
   • "aaaaaabb"
   • (native side receives the clear command)
   • "bbb" - Oops, the first two "bb"s were removed, as they happened before the event was received on the native side. The user would've expected to see "aaaaaa" -> "" -> "bbbbbb".

   Additionally the text input wouldn't be cleared immediately when calling clear(), but only when the native side receives the command.

   Solution 🅱: Control from a single thread / have one source of truth

   Currently when using the value prop, there are two sources of truth:

   1. The text in the native text input
   2. The value state in the JS thread

   One could think of a solution where the input is completely controlled by the value from JS. Meaning when a change happens, the change is first dispatched to JS, and only if the value property updates the update is reflected in the native view.

   ⚠️ Problems

   The updating of the native text input would be bound to the performance of the JS thread. Lets say its very busy and only "performs at 10 FPS", then our UI updates would appear lagging to the user.

   Solution 🅲: Maintain an event order by using timestamps

   When we update the state of the textInput component (using the value prop) we attach a timestamp of the event.

   Internally an order/stream of events is maintained from which the current displayed input text is constructed.

   • Text input is "aaaaaa"
   • User presses clear button, sending event { type: 'clear', timestamp: 1 }
   • User types "b", the native side stores the event with { type: 'text', text: 'b', timestamp: 2 }, now text input is "aaaaaab"
   • User types "b", the native side stores the event with { type: 'text', text: 'b', timestamp: 3 }, now text input is "aaaaaabb"
   • The native side receives the clear event, and puts it into the correct order:
     • { type: 'clear', timestamp: 1 }
     • { type: 'text', text: 'b', timestamp: 2 }
     • { type: 'text', text: 'b', timestamp: 3 }
   • The native input text shows "bb"
     So the user would see "aaaaaa" -> "aaaaaabb" -> "bb".

   The good part is that opposed to solution 🅰 we wouldn't drop any text.

   ⚠️ Problems

   Implementing an event order system is not trivial and could lead to a lot of complexity.

   Solution 🅳: Only apply partial updates from the native side to our JS value

   Instead of fully setting the whole native text we receive, we can only apply the updates that happened to the text to our JS value.

   Meaning if the input was "aaaaaa" and the user types "b", instead of taking the native text update and setting "aaaaaab" as our value, we just take the change "b" and append it to our value:

   • value is "aaaaaa"
   • User presses clear button, setting value to ""
   • User types "b"
   • Native side sends "aaaaaab"
   • JS just takes the partial diff value "b" and appends it to our value, resulting in "" + "b" = "b"
   • Native side is updated with the new value prop, showing "b"

   So the user would see "aaaaaa" -> "aaaaaab" -> "b".

   ⚠️ Problems

   For a brief moment the user might still see an unexpected input text "aaaaaab" before it gets updated to "b".
   However, we didn't drop any text and its quite easy to implement such a solution.

   Where to go from here

   The overarching problem is that we have two threads that communicate asynchronously with each other.
   While the JS thread dispatched a clear event and we're waiting on the native side to receive it, the user might have already typed new text on the UI thread.

   Given this architecture I feel like solution 🅳 is the most feasible one, as it doesn't require a complete rewrite of the text input component and is quite easy to implement.

   We only need to add information about the range in which the native text was changed. I created a PR here, which does that:

   • feat: include information about text range changes in onChange #45248

   I applied the changes from the PR to the reproducer of this issue:

   Before	✨ After ✨
   BEFORE.webm	FIXED.webm

   ❤️React with ❤️1Reacted by Jakub Trzebiatowski
7. hannojg commented on Jul 18, 2024

   

   hannojg

   on Jul 18, 2024

   Contributor

   More actions

   I started a discussion here to discuss with meta how to fix this:

   • `TextInput`: Fix clearing issues w/ methods to circumvent the event count to force set a value from JS react-native-community/discussions-and-proposals#803

   👍React with 👍2Reacted by Jakub Trzebiatowski and NB
8. altmshfkgudtjr commented on Nov 8, 2024

   

   altmshfkgudtjr

   on Nov 8, 2024

   More actions

   Is there any solution to this issue?

   I’m currently working on a project, but I’m having difficulty finding an alternative approach.