react-native: TextInput becomes slow after lots of typing

Updated labels and flagged this as a high priority. Hopefully we can get this fixed as soon as possible.

I think closing this is a little premature. This is a major issue that has affected the entire user base for several years. This issue alone has caused several developers i know personally to abandon react native due to frustration and hundreds of hours of lost productivity. I think it deserves some more thorough testing. And if it is fixed, maybe we can find the commit that fixed it and the reason it was broken in case it turns up again in the future.

I am experiencing this issue on RN 0.63.2 and it appears to be exactly what @fabriziobertoglio1987 is pointing to. If I remove value then TextInput is super fast. Many users on Android 8/9 phones (a little old, but not walkie talkies) are reporting that it is buggy to use the TextInput.

I am using a workaround where I remove the value prop. I set a defaultValue and use onChangeText to listen to changes. This stops the bugginess since it doesn’t have to make the round trip explained above.

Even in the react-native docs they mention this flicker (I guess) https://reactnative.dev/docs/textinput#value

value: The value to show for the text input. TextInput is a controlled component, which means the native value will be forced to match this value prop if provided. For most uses, this works great, but in some cases this may cause flickering

Has anyone had bad experiences from using defaultValue and onChangeText?

For me the only stable solution to avoid any lags is to use uncontrolled TextInput which means DON’T use value field. You can manage that in 2 ways:

1. Use _lastNativeText…

addNewTodo = () => {
    const value = this.addTodoRef._lastNativeText

    if (value) {
        this.props.actions.addTodo(value)
    }
}

render() {
    <TextInput
        ref={component => { this.addTodoRef = component }}
        onSubmitEditing = {this.addNewTodo}
        blurOnSubmit
    />
}

but in this case this.addTodoRef.clear() and this.addTodoRef.setNativeProps({text: ''}) will not empty _lastNativeText, so this solution requires even more hacks above that

1. Use onChangeText with class property

textInputValue = null

addNewTodo = () => {
    const value = this.textInputValue

    if (value) {
        this.props.actions.addTodo(value)
        this.addTodoRef.clear()
        this.textInputValue = null
    }
}

onChangeText = (text: string) => {
    this.textInputValue = text
}

render() {
    <TextInput
        ref={component => { this.addTodoRef = component }}
        onSubmitEditing = {this.addNewTodo}
        blurOnSubmit
        onChangeText={this.onChangeText}
    />
}

hey everyone, I’m sorry this issue is still around. As @sintylapse wrote about, the FB team is currently working on a rewrite of the RN architecture - you can find more details in the pinned issues in this library https://github.com/react-native-community/discussions-and-proposals/issues.

Anyway, this has been a fairly important issue - I’ll try to raise it again with the FB team, maybe there is some intermediate step that can be taken to make the situation better.

In the meantime, the PR process flow has improved greatly in the past few months so if you have any tweaks that could help please submit a PR 🤗

for me the solution was to do the following

https://snack.expo.io/@jerson/text-input-slow-fix

 _onChange = (label) => {
     if (this.timeoutUpdate) {
      clearTimeout(this.timeoutUpdate);
    }
    this.timeoutUpdate = setTimeout(() => {
      this.input.setNativeProps({
        text: label
      });
    }, 100);

    this.setState({ label })
  }

For anyone having doubts about my workaround:

I have been using my solution posted above in my app with 40k MAU and I haven’t seen a single report or issue.

Happy coding!

It’s odd that this video wasn’t mentioned so far. https://youtu.be/83ffAY-CmL4?t=1366

Of course this is a serious issue, but I think everyone should wait for the awesome work the core team is doing.

OK I have been elbows deep in this issue for a week, I would not have considered myself strong on the Native code side of things, but I think I can at least confirm the original hypothesis that large numbers of spans are being created…

By attaching a breakpoint in /com/facebook/react/views/textinput/ReactEditText.class:395 (manageSpans() method) I can see that as the input is used the number of CustomLineHeight spans on it grows continuously, not being removed when the input is cleared or the text the span affects is deleted. From my understanding this could be other styling spans too - it just happens to be customLineHeight spans in my case because that is the styling I am using.

From what I can tell this is caused by the combination of a few things -

1. The CustomLineHeight class is not one of the classes checked at the start of manageSpans() in:

      // Remove all styling spans we might have previously set
      if (ForegroundColorSpan.class.isInstance(spans[spanIdx]) ||
          BackgroundColorSpan.class.isInstance(spans[spanIdx]) ||
          AbsoluteSizeSpan.class.isInstance(spans[spanIdx]) ||
          CustomStyleSpan.class.isInstance(spans[spanIdx]) ||
          ReactTagSpan.class.isInstance(spans[spanIdx])) {
        getText().removeSpan(spans[spanIdx]);
      }

1. Although in sameTextForSpan() it specifically checks to see if the span is for a section of text that no longer exists, and does not add the span to the new SpannableStringBuilder it is building to replace the existing text with, this doesn’t help because…
2. back in maybeSetText() we call getText().replace(0, length(), spannableStringBuilder); however this replaces the text spans from 0 to the new length, not the old one, leaving the spans related to deleted text alive and kicking.

I tried changing the second param to the previous length of the text, however unfortunately this makes the Editable throw and out of range exception as it already considers it’s length to be that of the new text (Even though it is still hanging on to the references to the spans that run outside of that new text’s bounds).

What did seem to help for me was to add CustomLineHeight as one of the classes to check for the removal of style spans. As above - this just happens to be the styling spans that I am using, but other use cases may need other span classes added there. Seeing as the span is being removed directly, rather than replaced, it seems to work out.

What this does not explain is the experiencing of this issue without clearing or deleting text - that I have no clue about - but certainly as per @netdesk and @stueynet above I was still seeing the performance issues after clearing text even after applying the patch from https://github.com/facebook/react-native/pull/19645 .

Hopefully this points someone with more knowledge of the Android TextInput code in the right direction

There’s no reason to believe this has been fixed. Stale-bot please go away.

Wow, that would be exciting! But also scary. I tried to make sure there were no behavior changes when I rewrote it

After few tests I`ve discovered that clean InputText (without any styling) works normally (sometimes fps going down, but app is not freezing). But if I add some styling to input (e.g. fontSize) then typing process is going to be laggy more and more.

Unstable behavior is appear much faster if quantity of styling options is more. It seems that something went wrong with styling span generation (size, lineHeight, letterSpace and so on) inside of the logic of the text shadow nodes code.

For now, i have to remove all styling from inputs, to get app works.

Maybe that helps someone. Cheers!

This has gotten worse recently since we’ve upgraded to RN 67 and we’ve begun receiving reports of more lag and even crashing (“App isn’t responding…”) . None of the fixes suggested above seem to work. Any updates on RN core side @kelset @bvaughn, etc?

In my case, the TextInput becomes slow when starting typing. I noticed that autocorrect takes some time to suggest words on the keyboard and so I turned it off. Now it works better. I know it’s not the best solution, but … ¯ \ _ (ツ) _ / ¯

autoCorrect={false}

@kelset Are you sure? I thought this was an architectural issue as mentioned by @axe-fb here: https://youtu.be/83ffAY-CmL4?t=1366

This is the current problem (slides from infinite-red video and the solution is from @nparashuram)

You type R and you set value of R to the field.

You add E to R (RE) and another call to onChangeText is triggered, at the same time callback setText('R') is called

and now setText('RE') is called again while the user keeps updating that field and adding callback that are slowing down the app

WORKAROUND from @nparashuram

Add a debounce function, that delays calling onChangeText every 100 milleseconds

SOLUTION from @nparashuram

The solution that he proposes at minutes 24:55 (for the new react-native versions) is to use syncronous calls instead of asyncronous.

You type R --> syncronous call setValue('R') --> you type E --> syncronous call setValue('RE')

https://formidable.com/blog/2019/fabric-turbomodules-part-3/

We are having similar issues on React Native 0.67 and Android 13 users.

We have a chat screen with a TextInput at the bottom. Removing everything but style, multiline and scrollEnabled results in the app suddenly slowing down after about one minute of doing nothing or typing a few letters. Dismounting the input by leaving the screen restores any slowdown. The TextInput simply seems to implode even without reading or writing to it via the onChangeText, defaultValue or value props.

Not the ideal solution, but I’ve also found that turning off autoCorrect as suggested above has a significant positive performance impact with large text.

Device: Samsung Galaxy S10 Android Version: 12 React-Native Version: 0.64.0

That’s great to hear! Given that we sort of have a 3-way confirmation on this not being an issue in latest versions, I’ll be optimistic and close this issue.

If someone can repro this with latest 0.61.x AND 0.62 RC please link it below and we can reopen this.

oh wow that’s great to hear! It’s probably related to the fact that @TheSavior re-wrote TextInput completely to use hooks… if anyone else can test with the RC1 and confirm it would be super helpful!

0.58.6 - the problem persists.

Hi,

I’m experiencing the same problem with 3 separate react native apps under developpement.

I have conducted my small tests with the slightlyest modified basic App (but trying with “PureComponent” - see below) with the following versions :

• 0.54.0
• 0.55.x series
• and the 0.56.1 version.

There are differences, but as far as I can tell, the behaviour is basically the same : performances drop after a couple of hundreds of typing (300 words / 1000 carateres). So, could this be inherent to react native &/or mobile dev ?

There are aggravating factors, though :

• Maybe, as @alp1396 reported above, text styling is a “bug” amplifier, I haven’ tried
• With 0.55.x (not tested with 0.54 nor 0.56), when <TextInput onChange={this._onChange} value={this.state.value} /> is replaced by <TextInput onChangeText={this._onChange}>{this.state.value}</TextInput>, performances are dramatically decreased (but this is not “by the book” anyway). 0fp is reached after 500 caracters or so. ;
• With no value={this.state.value} inside the TextInput component, it is much better. At 1200 caracters, it is still around 45-55fps, which is acceptable.

My projects must allow the user to compose large pieces of texts, so I guess I will keep an eye on it, and try various workarounds to mitigate it (unmount the component + no value={this.state.value} when admissible…).

Thanks a lot for any update on this issue.

import React from 'react';
import { StyleSheet, Text, View, TextInput } from 'react-native';

export default class App extends React.PureComponent {

  constructor(props) {
    super(props)
    this.state = {
      label : ''
    }
  }

  _onChange = (label) => {
    this.setState({ label })
  }

  render() {
    return (
      <View style={styles.container}>
       <Text>Caracter count : {this.state.label.length}</Text>
        <Text>Word count : {this.state.label.split(' ').length}</Text>
        <TextInput 
          onChangeText={this._onChange}
          value={this.state.label}
        />
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

How can such an essential component be buggy since 5 years? Not asking to annoy somebody, just questioning, if there’s something wrong with notifications, some missing label, or whatever is needed that this issue is seen by some maintainer.

We did a lot of experimenting in the last days, and our issue is clearly linked to the Google Keyboard app. I don’t know if it’s the exact same issue like this one discussed here, because we could reproduce it down to RN 0.50 (simple app with just a TextInput like my example above). In 0.49 it was not reproducible, from 0.50 to 0.57rc4 we could reproduce it. In our current app in development an external keyboard is used, it’s easier to reproduce then because you can hammer the physical keys, CTRL+A, Delete, hammer again, and repeat that a couple of times until it becomes slower and slower. We tried to reset our test devices, after reset the slowness was gone, until the Google Keyboard updated in the background from 4.* to 7.* - then the slowness immediately touched in. Downgrading Google Keyboard to 4.* or deactivating it totally fixes the issue immediately. We tried some other keyboards. With Swift keyboard it’s slow too, there you see that our test device does hard work when updating swift’s vocabulary suggestions, but it’s usable and doesn’t slow down with every cleaning of the input - it’s just a bit slow from the beginning. Other keyboards like Chrooma or Go also introduce some slowness, but you only see it if you hammer the physical keys with flat hands and fingers, not if you type normally. With Google Keyboard 7.* enabled, it becomes slower and slower with every clearing of the TextInput. If you disable voice keyboard and then uninstall all keyboard apps, (you can’t disable the voice keyboard when it’s the only keyboard left so you have to disable it before you uninstall the last keyboard app), so, there is no software keyboard left, then there is zero slowness, nothing. Maybe it’s not directly related to this issue, but at least the effect is the same.

I have upgraded our app to 62-rc-0 and this does not appear to be an issue on Android for me.

I’ve made bunch of tests with different RN versions and the explanation is the only one: from October 2017 the issue remains from RN 0.50. As I see in changelog there were lots of changes including TextInput and TextShadowNode. The code below works fine in RN 0.49.

@piotrpazola Cool, that is very helpful new information!

The next step, if you’re (or anyone else is) up for trying it, would be to do the same thing with different RN versions between v0.49 and v0.50, from Git. The goal would be to pin down a single commit that introduced the issue. Then that will be a very powerful clue for diagnosing the issue – that’s exactly how I diagnosed and fixed the related issue #19126.

There are 306 commits in that range; so with the magic of binary search, you’ll need to try 9 different versions (because 2^9 >= 306 > 2^8).

$ git rev-list --count v0.49.0..v0.50.0
306

Git has a handy utility git bisect that can help manage the binary search for you, or you can also just do it by hand. (Try it on the midpoint v0.50.0~153, etc.)

For running with an RN version from Git, see this page of docs: https://facebook.github.io/react-native/docs/building-from-source.html

Here’s my mod in a package https://www.npmjs.com/package/react-native-no-lag-text-input for easier testing.

@tarouboy if you could let me know what text selection / typing problems you’re facing, I will take a look.

I found a way to make the delay go away, without workarounds that avoid using the TextInput value or debouncing onChangeText() (and I’m stressing it quite a bit, using a barcode scanner that creates 13 chars within 0.5s).

I’ve completely bypassed the SpannableStringBuilder and I don’t know if that creates other problems (I don’t see any styling going away, even with properties that seem to want to use spans (e.g. letterSpacing)). All I know is that the delay has gone away, I see no issue in my app and after looking into this for days, I’m too tired to care about anything else. If anyone wants to test it out, you can use this in your package.json:

"react-native": "github:bdokimakis/react-native.git#0.63-stable-with-fix-for-20119"

Any feedback would be appreciated.

Given that 3 different developers confirmed separately that the issue is fixed for them I thought it would be good to close it to signal to the other developers in the issue that there has been “an evolution” on this subject (as probably many people don’t open the notification about it when simply new comments are added). But I see your point @rspenc29 so I’ll reopen.

I think it deserves some more thorough testing. And if it is fixed, maybe we can find the commit that fixed it and the reason it was broken in case it turns up again in the future.

If you could help with that it would be great, as my bandwidth is quite limited.

Anyone checked this bug in 0.61? Is it any better?

The next step, if you’re (or anyone else is) up for trying it, would be to do the same thing with different RN versions between v0.49 and v0.50, from Git. The goal would be to pin down a single commit that introduced the issue. Then that will be a very powerful clue for diagnosing the issue – that’s exactly how I diagnosed and fixed the related issue #19126.

@gnprice Thank you for advices! I’m glad that it could help because it really makes me bad. If I get some extra time I’d build some middle versions of RN between 0.49 and 0.50 and I’ll do the same tests. I spent some time digging in java code of TextInput and so on, comparing implementations of 0.49 and 0.50 versions. There were lots of changes and it’s unclear what could went wrong. Hopefully, we’ve got the best chance to fix this that ever.

0.57.8 still have this problem. +1

The above does not work(and should! because a standard-text-input should just work!). Please update main-readme with the following text: TEXT-INPUT DOES NOT WORK! Because THIS is a SHOWSTOPPER for any app but it takes some useless time debugging(and writing an entire app based on RN) to get it.

AFAIK there is no PR directly related to this issue currently open, feel free to implement something if you can.

There are currently a lot of things going on with the repo, so I have no estimate on when this can be picked up.

See more info in this comment https://github.com/facebook/react-native/issues/20119#issuecomment-639482512 It is caused by TextInput controlled components.

Possible solution: When we reach a lot of update and consequential slow down in the performance, instead of batching 1 update for each letter we type (onChangeText triggers every time we type a character), we send multiple characters all at once

For example

1. User types in the TextInput “Hello World”

Now react-native does like this:

1. JS TextInput sends “H” to Java EditText
2. Java EditText shows H in the TextInput
3. Java notifies JS TextInput that H was added on the EditText
4. JS repeats 2-4 for every character

Instead we could add logic in the TextInput API, in case user types 5 characters per second:

1. JS TextInput sends "Hello" to Java EditText
2. Java EditText shows Hello in the TextInput
3. Java notifies JS TextInput that Hello was added on the EditText
4. JS repeats 2-4 for the second word "World"

It could enabled by default or disabled by default with a prop batchWordsToOptimizePerformanced. The batching of words instead of characters would be used ONLY when the user types extremely fast and the TextInput is very laggy.

The issue was opened 6 years ago. It should have been resolved with the new architecture. Does somebody experience this with new architecture? Should I prepare a fix or nobody is interested in this anymore? Thanks

the solution for this issue is create a method that uses the RNBridge syncronously instead asyncronously as explained in #20119 (comment) not worth it creating a pr as the react native team is working on the new architecture which should solve all the limitation from the react native bridge

As I mentioned, I did not set the value attribute and also with a debounced onChange ( so no async callback I suppose? ), but the performance drop remains. I have received more than 10 reports mentioning it will cause the keyboard lag with serious delay, even after quitting the app. They will have to restart the device to back to normal.

For me, I could easily reproduce the performance drop even with flagship devices by pasting around 15-20k characters into the textInput. Maybe it’s a rare case in most the app but for a diary or note-taking app it’s quite normal.

If anyone could provide any workaround or a temp fix, I am willing to donate.

Thanks.

Same experience here, and I don’t need to put that many characters in, putting in a few sentences and removing it by holding the backspace button a few times does it on iPhone X.

@kelset Are you sure? I thought this was an architectural issue as mentioned by @axe-fb here: https://youtu.be/83ffAY-CmL4?t=1366

Cool - thanks everyone. When 0.62.0 is out I’ll close this then.

Just tested on 0.62.0-rc.2 works perfect!!! TextInput now not freeze UI and onChangeText() setState() not lagging anymore, not need to make workaround like: this.inputRef.current._lastNativeText;

I spent some time digging in java code of TextInput and so on, comparing implementations of 0.49 and 0.50 versions. There were lots of changes and it’s unclear what could went wrong.

Makes sense! Yeah, the powerful thing about git bisect (or doing the equivalent by hand) is that you can narrow it down to a much smaller diff, to go back and study in exactly that way.

Especially when a bug is something subtle, that can make a big difference because it lets you look much more closely (because there is less to look at)… and also, it gives you much more traction to start making logical inferences about what’s going on, just like how in a scientific experiment you always try to change just one or a few variables at a time.

If I get some extra time I’d build some middle versions of RN between 0.49 and 0.50 and I’ll do the same tests.

Great 😄

I’ve made bunch of tests with different RN versions and the explanation is the only one: from October 2017 the issue remains from RN 0.50. As I see in changelog there were lots of changes including TextInput and TextShadowNode. The code below works fine in RN 0.49.

state = {
      code: '',
      count: 0,
    }

  _scanCodeEndEditing = () => {
    let code=this.scanCodeInput._lastNativeText;
    let count=this.state.count+1;
    this.setState({
      code,
      count
    });
    this.scanCodeInput.clear();
    this.scanCodeInput.focus();
  }

  render() {
    return (
      <View style={styles.container}>
        <Text style={styles.welcome}>
          Test RN0.49 width 100
        </Text>
        <Text>{this.state.code}</Text>
        <Text>Count: {this.state.count}</Text>
        <TextInput
          style={{width: 100}}
          onEndEditing={this._scanCodeEndEditing}
          ref={input => { this.scanCodeInput = input }}
        />
      </View>
    );
  }

Downgrading my project is the only solution for me for now. I can make 20-30 scans in 1 minute by bluetooth HID interface scanner of datamatrix code including 50 chars per scan into the single inputtext and nothing get laggy. From RN0.50 is impossible to do this, it’s getting laggy really hard from 6-8th scan so it’s something around 300-400 chars sent and the device needs to be restarted, not only the app. Really annoying.

For me the only stable solution to avoid any lags is to use uncontrolled TextInput which means DON’T use value field. You can manage that in 2 ways:

1. Use _lastNativeText…

addNewTodo = () => {
    const value = this.addTodoRef._lastNativeText

    if (value) {
        this.props.actions.addTodo(value)
    }
}

render() {
    <TextInput
        ref={component => { this.addTodoRef = component }}
        onSubmitEditing = {this.addNewTodo}
        blurOnSubmit
    />
}

but in this case this.addTodoRef.clear() and this.addTodoRef.setNativeProps({text: ''}) will not empty _lastNativeText, so this solution requires even more hacks above that

1. Use onChangeText with class property

textInputValue = null

addNewTodo = () => {
    const value = this.textInputValue

    if (value) {
        this.props.actions.addTodo(value)
        this.addTodoRef.clear()
        this.textInputValue = null
    }
}

onChangeText = (text: string) => {
    this.textInputValue = text
}

render() {
    <TextInput
        ref={component => { this.addTodoRef = component }}
        onSubmitEditing = {this.addNewTodo}
        blurOnSubmit
        onChangeText={this.onChangeText}
    />
}

This is a good way, but it will still slow down after a thousand edits.

demo gif link

Here is a demo

0.57.7 still have this problem

@piubellofelipe I’d recommend using @sintylapse’s temporary solution until it’s fixed. Graceful enough for me in the meantime!

So @gnprice can we confirm this is still not fixed even in 0.57 and the issue seems to be related to the value prop on the text input. Using the @sintylapse hack above the issue does not appear to be a problem. Perhaps this will help in terms of figuring out a solution?

To summarize 0.54 and 0.55 are essentially unusable on Android. 0.56 has a partial mitigation of the problem which lets you type for longer but likely will start to be problematic just after more typing.

Thank you so much @sintylapse!!!

Any updates on that? Still reproducible in 0.57rc4. Just create a new react native project and use this simple App class:

export default class App extends Component<Props> {
    render() {
        return (
            <TextInput />
        );
    }
}

As the TextInput is unstyled, you won’t see it, just click in the top left corner, then the cursor appears. After several recursions (3-5) of typing and clearing the whole text, the lag is noticable, from then on the lag increases every time you clear. On our test device, also other apps are slow then, e.g. the Chrome address bar lags just like the RN TextInput. Only a restart of the device fixes it, but it appears again after some recursions of typing and clearing.

This issue started in 0.54 and still exists today. Any chat app that uses a text input that persists between messages becomes unusable after only a few minutes if chatting. I wish there was some way to get this fixed.