[IOS] Incorrect behavior of hooks and components when focusing on an input with secureTextEntry enabled.

[A-Yatsyk]

Describe the bug

When focusing on a field with secureTextEntry set to true (iOS only), UI misbehaves with KeyboardAvoidingView, causing erratic jumping. In useKeyboardHandler, onStart will be called with progress 1, followed immediately by onEnd with progress 1, and only after these (prior onStart and onEnd) will correct calls of onStart, onMove, and onEnd occur.
This behavior is also observed in KeyboardEvents, where the first listener is wrong, and only after that, do true listener calls follow.

A similar issue was present in React-Native itself, but it was fixed since KeyboardAvoidingView in React-Native now works as expected for iOS (e.g., facebook/react-native#39411).

Code snippet

<KeyboardAvoidingView
      behavior="padding"
      style={{ flex: 1 }}
      contentContainerStyle={{ flexGrow: 1 }}
>
    <SafeArea style={{ flex: 1 }}>
        <ScrollView
            bounces={false}
            style={{ flex: 1 }}
            keyboardShouldPersistTaps="handled"
            contentContainerStyle={{ flexGrow: 1, paddingHorizontal: 25 }}
        >
            <View style={{ flex: 2 }} />

            <TextInput
                placeholder="Placeholder"
                secureTextEntry
                style={{
                    height: 45,
                    borderWidth: 1,
                    borderColor: 'gray',
                    borderRadius: 10,
                    paddingHorizontal: 10,
                }}
            />

            <View style={{ flex: 1 }} />

            <View style={{ alignItems: 'center' }}>
                <Text>Footer</Text>
          </View>
        </ScrollView>
    </SafeArea>
</KeyboardAvoidingView>

To Reproduce
Steps to reproduce the behavior:

1. Add secureTextEntry with a value of true to the field.
2. Wrap the screen using KeyboardAvoidingView.
3. Focus on the field with a closed keyboard.

OR

1. Add secureTextEntry with a value of true to the field.
2. Add useKeyboardHandler with handlers for onStart, onMove, onEnd using console.log.
3. Focus on the field with a closed keyboard (the first onStart and onEnd won't reflect reality)

Expected behavior

Expected behavior should be the same as when the secureTextEntry is set to false

Screenshots

Screen.Recording.2024-01-12.at.14.48.41.mov

Smartphone:

• Desktop OS: MacOS 14.2.1
• Device: iPhone15
• OS: iOS 17.2
• RN version: 0.70.13
• RN architecture: paper (old)
• JS engine: Hermes
• Library version: 1.10.1

[wanted-o]

Have the same issue.

[oleksandr-dziuban]

Same issue

[kirillzyusko]

Interesting, I think this bug was introduced in iOS 17. A similar issue was raised quite long time ago: #243

But I'll have a look on it 👀

[A-Yatsyk]

Interesting, I think this bug was introduced in iOS 17. A similar issue was raised quite long time ago: #243

But I'll have a look on it 👀

Thank you, as this is a critical issue for working with animations. If we take into account useKeyboardHandler, KeyboardAvoidingView can be replaced with the one from the "react-native" package (for iOS for now).🤞

This library is the only one that truly helps interact with the keyboard for animations. The rest are too buggy. 😅

[kirillzyusko]

@A-Yatsyk does this problem happens on 1.10.0? It seems like the problematic code was introduced in #316, am I right?

[kirillzyusko]

@A-Yatsyk it should be fixed in #331 can you please check? 👀

[A-Yatsyk]

@A-Yatsyk it should be fixed in #331 can you please check? 👀

This is better than it was. If you watch the video, you can see that there are still occasional glitches. We still have duplications of onStart/onEnd handler calls.

Screen.Recording.2024-01-13.at.13.33.33.mov

[A-Yatsyk]

@kirillzyusko at the moment when glitches occur in KeyboardAvoidingView, in the logs for useKeyboardHandler, you can observe the following:

1. onStart => { height: 291, progress: 1, ... }
2. onEnd => { height: 291, progress: 1, ... }
3. onStart => { height: 336, progress: 1, ... }
4. onMove => { height: 49.28188181016594, progress: 0.14667226729216054, ... }
   ..........
5. onMove => { height: 336, progress: 1, ... }
6. onEnd => { height: 336, progress: 1, ... }

[kirillzyusko]

Yes @A-Yatsyk

If you add keyboardWillShow listener to plain react-native module, you'll also see that native side is emitting this additional event:

 LOG  onStart {"duration": 250, "eventName": "onKeyboardMoveStart", "height": 291, "progress": 1, "target": 473}
 LOG  keyboardWillShow 291
 LOG  onStart {"duration": 250, "eventName": "onKeyboardMoveStart", "height": 336, "progress": 1, "target": 473}
 LOG  keyboardWillShow 336

The thing is that I can not filter out bad event from a native code and I have to propagate it to JS 😔 The bug was actually in useKeyboardInterpolation hook. Such case, when onStart is triggered two times with positive height value is similar to what happens when keyboard size is changed on Android. And useKeyboardInterpolation relies that after keyboard resize we'll get new range [291, 336] and keyboard height will be in this range. However it's not the case because real keyboard height will be changing from 0 to 336, and because of that interpolated value will be a negative number.

If I change interpolation mechanism, then we'll see an expected output, because these 2 events are emitted after each other and we'll interpolate to las frame (i. e. from 0 to 336). So in #331 I'm fixing KeyboardAvoidingView integration, but I don't think it's possible to fix useKeyboardHandler hook just because OS is emitting these events on its own and we don't have any way to verify whether it's valid keyboard frame or not. Does it make sense what I'm saying?

This is better than it was. If you watch the video, you can see that there are still occasional glitches. We still have duplications of onStart/onEnd handler calls.

Got you. I will try to experiment more to see why these glitches actually happen (I know it's because of duplicated events, but will try to find a way to ignore them somehow)...

P. S. such glitch happens because in onEnd we update the value, so before the next onStart we'll have fully interpolated value, i. e.:

 LOG  onStart {"duration": 250, "eventName": "onKeyboardMoveStart", "height": 291, "progress": 1, "target": 1377} 1705151792325
 LOG  0 [0, 291]
 LOG  {"bottomHeight": 0}
 LOG  keyboardWillShow 291
 LOG  keyboardWillShow 291
 LOG  onEnd {"duration": 250, "eventName": "onKeyboardMoveEnd", "height": 291, "progress": 1, "target": 1377} 1705151792333
 LOG  291 [0, 291]
 LOG  {"bottomHeight": 139}
 LOG  onStart {"duration": 250, "eventName": "onKeyboardMoveStart", "height": 336, "progress": 1, "target": 1377} 1705151792335
 LOG  291 [0, 336]
 LOG  {"bottomHeight": 159.35714285714286}
 LOG  keyboardWillShow 336
 LOG  keyboardWillShow 336
 LOG  45.18494185101008 [0, 336]
 LOG  {"bottomHeight": 24.744134823172185}

[A-Yatsyk]

@kirillzyusko yes, thanks, I understand, although it's actually strange that there is an onEnd callback indicating that the keyboard was opened with a height of 291, even though that's not the case, and an update is occurring.

[A-Yatsyk]

It would be good to find a way to fix this for KeyboardAvoidingView at least.

[kirillzyusko]

@A-Yatsyk I pushed f18e223 - can you again check whether it fixes all the issues?

[kirillzyusko]

@A-Yatsyk I pushed a PR with a fix into main and the issue got closed automatically. I'll publish a new 1.10.2 version in next hour. If you find that something is not working again (or working incorrectly) - feel free to re-open this issue or submit a new one 🙏

Thank you for you help in debugging this issue, active participation in resolution and the creation of such descriptive issue ❤️

[A-Yatsyk]

Thank you for the prompt resolution of the issue, the problem has been resolved 👍