New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Controlled TextInput broken for Chinese (and other languages) in v0.54 on iOS #18403

Closed
danielsuo opened this Issue Mar 16, 2018 · 39 comments

Comments

Projects
None yet
@danielsuo

danielsuo commented Mar 16, 2018

Controlled TextInput breaks the Chinese pinyin keyboard's autocomplete feature. A similar issue was raised a year and a half ago (#8265) and fixed by #7496. However, it appears that others are having the same problem (#12599, #18260, #18379), but re-filing the issue with the template filled out and an example to reproduce.

Note that this works correctly in v0.53. This may have something to do with the big Text, TextInput refactor that dropped with v0.54 (Thanks, btw, @shergin and @hovox!).

I've included both a working (v0.53) and broken (v0.54) example below.

Environment

Environment:
OS: macOS High Sierra 10.13
Node: 9.3.0
Yarn: 1.3.2
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.2 Build version 9C40b
Android Studio: Not Found

Packages: (wanted => installed)
react: 16.2.0 => 16.2.0
react-native: 0.54.0 => 0.54.0

Expected Behavior

Typing on a US keyboard would bring up Chinese characters corresponding to letters typed.

Actual Behavior

Each new letter typed is considered individually, instead of along with the previous untranslated characters.

Shamelessly stealing an image from @ForU who did a nice job of showing the issue:

image

Steps to Reproduce

Unfortunately, expo hasn't updated to the latest version of React Native. I've prepared a small project that demonstrates the issue here. There is a working version on a branch here; same project, just using RN v0.53 instead of v0.54.

@danielsuo danielsuo changed the title from Controlled TextInput broken for Chinese (and other languages) in v0.54 to Controlled TextInput broken for Chinese (and other languages) in v0.54 on iOS Mar 16, 2018

@hramos

This comment has been minimized.

Contributor

hramos commented Mar 16, 2018

Great bug report! Thanks for organizing all of the reports.

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

@danielsuo I created a PR #18456 to fix this issue.
I made sure that it works for Japanese, but I'm not sure about Chinese.
I forked your test app and applied this change.
Can you (or anyone who can speak Chinese) try this app to check if it's fixed?

@BooYeu

This comment has been minimized.

BooYeu commented Mar 20, 2018

if it has prop value or defaultvalue,you can't input Chinese

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

Thank you @BooYeu! It might need to include #18278.
Let me update the PR.

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

I updated the pull request and the sample app.
And I tried one of Chinese keyboards. I hope it's expected behavior.
screenshot

@BooYeu

This comment has been minimized.

BooYeu commented Mar 20, 2018

I changed and tried again , but it doesn't work . Do you have the prop "defaultValue" like defaultValue=this.props.value ? I found it ok that using defaultValue="test"

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

I tried 2 cases, and both of them seemed working.

<TextInput
  placeholder="Type here!"
  onChangeText={text => {
    this.setState({ text: text });
  }}
>
  <Text>{this.state.text}</Text>
</TextInput>
<TextInput
  placeholder="Type here!"
  onChangeText={text => {
    this.setState({ text: text });
  }}
  value={this.state.text}
/>
@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

I tried receiving defaultValue as prop, and it also seemed working.

const TestComponent = ({ value }) => (
  <TextInput
    placeholder="Type here!"
    defaultValue={value}
  />
);

export default class App extends Component {
  constructor(props) {
    super(props);
  }

  render() {
    return (
      <View style={styles.container}>
        <TestComponent value="Default Text" />
      </View>
    );
  }
}

test2

@BooYeu

This comment has been minimized.

BooYeu commented Mar 20, 2018

Oh My fault . I appreciate your help !!! Thanks !!

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 20, 2018

All right. Thank you!

@danielsuo

This comment has been minimized.

danielsuo commented Mar 20, 2018

Works for me! Appreciate the quick fix!

@magicien

This comment has been minimized.

Contributor

magicien commented Mar 21, 2018

Thank you @danielsuo!
I'm going to update the test plan of the pull request.

@Rob117

This comment has been minimized.

Rob117 commented Apr 5, 2018

This wasn't merged into 0.54.4 right?
Is this in 0.55.0?

@mkjfeng01

This comment has been minimized.

mkjfeng01 commented Apr 9, 2018

0.55.0 has this problem

@johnxie

This comment has been minimized.

johnxie commented May 30, 2018

Any updates on this issue?

@mpyw

This comment has been minimized.

mpyw commented May 31, 2018

Currently the following comment provides the best solution

#18456 (comment)

@ben5276

This comment has been minimized.

ben5276 commented Jun 11, 2018

Has this been fixed in 0.56?

@vovkasm

This comment has been minimized.

Contributor

vovkasm commented Jun 11, 2018

@ben5276 I will test it shortly... but probably not, because I tracked commits to master, and did not see anything that looks like fix for TextInput :-/
Update: I confused this bug with #18874, so sorry, see comment below.

@vovkasm

This comment has been minimized.

Contributor

vovkasm commented Jun 11, 2018

I checked it, at first glance Japanese input seems to work. But I using it rarely, so can't be totally sure.
My test code is here: https://github.com/vovkasm/react-native-textinput-bug/tree/rn-0.56 (it is for another bug, so the application tries to filter input, but while filtering is broken, anyone can test anything :-)

@ghost

This comment has been minimized.

ghost commented Jun 22, 2018

@tsangwailam
Thank you. Here is HOC version

withHandleHandWritingTextInput.js

import React, { Component } from 'react';
import {
  Platform,
} from 'react-native';

// https://github.com/facebook/react-native/issues/18403
const withHandleHandWritingTextInput = (WrappedComponent) => {
  class HandleHandWritingTextInput extends React.PureComponent {
    render() {
      const { onChangeText, onBlur, ...rest } = this.props;

      return <WrappedComponent
        onChangeText={text => {
          this.tempText = text;
        }}
        onBlur={e => {
          if (onChangeText) {
            onChangeText(this.tempText);
          }
          if (onBlur) {
            onBlur(e);
          }
        }}
        {...rest}
      />;
    }
  }

  return HandleHandWritingTextInput;
}

export default withHandleHandWritingTextInput;

And in another js use by

import {withHandleHandWritingTextInput} from 'withHandleHandWritingTextInput.js';

const MyTextInput = withHandleHandWritingTextInput(TextInput);
@dogecrypto

This comment has been minimized.

dogecrypto commented Jul 6, 2018

Not solved yet? Temporally hack code maybe not good to tackle on...

@kevinkevw

This comment has been minimized.

kevinkevw commented Jul 11, 2018

I was facing the same issue.
After different tests. It seems to be fine if TextInput with onChangeText but not setting the value props.

<TextInput onChangeText={ text => this.setState({ inputText: text }) } />

And this.state.inputText returns exactly the same as what I can see from the screen.
Any potential problems if using TextInput without setting the value props?

@vovkasm

This comment has been minimized.

Contributor

vovkasm commented Jul 11, 2018

@kevinkevw, but most of times you need to set value. Without a value, how you would implement "reset" functionality, or set initial value?
And exactly without a value, you simple do not trigger this bug, because your TextInput now effectively uncontrolled.

@kevinkevw

This comment has been minimized.

kevinkevw commented Jul 11, 2018

@vovkasm Ah yes you're right. I got your point. But the bug itself still not yet been fixed.

Leaving it uncontrolled seems working fine in my case, I set the initial value by defaultValue props and I don't really have to reset the TextInput, maybe forcing a re-render? : /

@kk412027247

This comment has been minimized.

kk412027247 commented Jul 17, 2018

@ tsangwailam 唔该晒!!

@kk412027247

This comment has been minimized.

kk412027247 commented Jul 17, 2018

未命名.gif

@tsangwailam In order to be compatible with android, I change some code.
The following code work well for me.

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


export default class App extends Component {

  state= {
    text:"", // hold the final text
    text2:"", // temporary store the input text
  };

  handleInput = (text) =>  this.setState({ text2: text });
  handleDisplay = (text) =>  this.setState({text:text});

  render() {
    return (
      <View style={styles.container}>
        <TextInput
          value={this.state.text}
          placeholder={'type here'}
          onChangeText={Platform.OS ==='ios' ? this.handleInput : this.handleDisplay}
          onBlur={ Platform.OS ==='ios' ? this.handleDisplay.bind(null,this.state.text2) : null}
        />
        <Text style={styles.text}>{this.state.text}</Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
  },
  input:{
    width:'100%'
  },
  text: {
    textAlign: 'center',
    margin: 20,
    color:'#999'
  },
});

@mmmulani

This comment has been minimized.

Contributor

mmmulani commented Jul 30, 2018

I just landed a fix for this on iOS. Please try it out and let me know if it doesn't work for this problem.

@hramos hramos added the Fixed label Jul 30, 2018

MarkRunWu added a commit to MarkRunWu/react-native that referenced this issue Jul 31, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

sidnair added a commit to thesegovia/react-native that referenced this issue Aug 2, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

lhcn added a commit to lhcn/react-native that referenced this issue Aug 7, 2018

@Taphood

This comment has been minimized.

Taphood commented Aug 8, 2018

Which official release is going to have this bug fix? In RN0.56 I'm still seeing this issue

@krizpoon

This comment has been minimized.

krizpoon commented Aug 9, 2018

Based on @tsangwailam 's solution, I came up with the following component. It works as a drop-in replacement (almost, except for the ref prop). It would work with external changes to the text value too.

import React, { PureComponent } from 'react';
import { TextInput, Platform } from 'react-native';
import ReactNativeVersion from 'react-native/Libraries/Core/ReactNativeVersion';

export function fixComposeInput(Component) {
    return class MyTextInput extends PureComponent {
        state = { diffKey: 0, value: '', display: '' };

        static getDerivedStateFromProps(props, state) {

            if (!state || !state.props || props.value !== state.props.value) {

                const value = props.value || '';
                const display = state && state.display || '';
                if (value !== display) {
                    const diffKey = ((state && state.diffKey) >>> 0) + 1;
                    return { props, value, display: value, diffKey };
                }
            }

            return { props };
        }

        handleChange = text => {
            // keep track of the display value
            this.setState({ display: text }, () => {
                const { onChangeText } = this.props;
                onChangeText && onChangeText(text);
            });
        };

        render() {
            const { refInput, value: valueProp, onChangeText, ...inputProps } = this.props;
            const { value, diffKey } = this.state;

            return <Component
                { ...inputProps }
                key={ `TextInput${diffKey}` }
                ref={ refInput }
                value={ value }
                onChangeText={ this.handleChange }
            />;
        }
    };
}

const rnVer = ReactNativeVersion.version.minor;

export default (Platform.OS === 'ios' && rnVer >= 54 && rnVer <= 56 ? fixComposeInput(TextInput) : TextInput);

sidnair added a commit to thesegovia/react-native that referenced this issue Aug 21, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

MarkRunWu added a commit to MarkRunWu/react-native that referenced this issue Aug 24, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

MarkRunWu added a commit to MarkRunWu/react-native that referenced this issue Aug 24, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

ide added a commit to expo/react-native that referenced this issue Aug 31, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

Fanghao added a commit to discordapp/react-native that referenced this issue Sep 6, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

wxsms added a commit to wxsms/react-native that referenced this issue Oct 9, 2018

Fix controlled <TextInput> on iOS when inputting in Chinese/Japanese
Summary:
@public
This should fix facebook#18403.
When the user is inputting in Chinese/Japanese with <TextInput> in a controlled manner, the RCTBaseTextInputView will compare the JS-generated attributed string against the TextInputView attributed string and repeatedly overwrite the TextInputView one. This is because the native TextInputView will provide extra styling to show that some text is provisional.
My solution is to do a plain text string comparison at this point, like how we do for dictation.

Expected behavior when typing in a language that has "multistage" text input: For instance, in Chinese/Japanese it's common to type out the pronunciation for a word and then choose the appropriate word from above the keyboard. In this model, the "pronunciation" shows up in the text box first and then is replaced with the chosen word.
Using the word Japan which is written 日本 but first typed as にほん. It takes 4 key-presses to get to 日本, since に, ほ, ん, are all typed and then 日本 is selected. So here is what should happen:

1. enter に, onChange fires with 'に', markedTextRange covers 'に'
2. enter ほ, onChange fires with 'にほ', markedTextRange covers 'にほ'
3. enter ん, onChange fires with 'にほん', markedTextRange covers 'にほん'
4. user selects 日本 from the menu above the keyboard (provided by the keyboard/OS), onChange fires with '日本', markedTextRange is removed

previously we were overwriting the attributed text which would remove the markedTextRange, preventing the user from selecting 日本 from above the keyboard.

Cheekily, I've also fixed an issue with secure text entry as it's the same type of problem.

Reviewed By: PeteTheHeat

Differential Revision: D9002295

fbshipit-source-id: 7304ede055f301dab9ce1ea70f65308f2a4b4a8f

(cherry picked from commit 892212b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment