-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
Include existing height when calculating new one for KeyboardAvoidingView #34749
Include existing height when calculating new one for KeyboardAvoidingView #34749
Conversation
@NickGerleman has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
This pull request was successfully merged by @pfulop in f85e2ec. When will my fix make it into a release? | Upcoming Releases |
Was the merge reverted? This bug popped again in RN 0.70.2. |
I can confirm the bug is here again in RN 0.70.5 Android/ios, |
@Orange9000 @dranitski Here, you can find the version that includes PR. |
It's very important task, thank you. |
…View (facebook#34749) Summary: Currently, height is sometimes the only valid option for pushing `TextInput` up in the layout on Android. The problem is when switching keyboards. For instance, switching from ABC to emojis. This will trigger keyboard show events and recalculate the height for the `KeyboardAvoidingView`. Since the keyboard is still showing, the view has the height that was previously calculated and thus `frame` represents that. This means the `frame.height` has adjustments for the keyboard calculated in it, but it is used the same way as if the keyboard was not showing. This results in wrong calculation and the input showing at the incorrect place in the layout (mostly hidden under the keyboard) This fix simply uses the previous calculation to offset `frame.height`, resulting in the correct height and smooth switching between keyboards. It's also scoped only to height mode since that's where the problem shows. _Note: I mention android here, but it fixes it for both platforms. It's just that iOS usually works best with different behaviour so it's rarely used there._ ## Changelog [General] [Added] - Include `this.state.bottom` when calculating new keyboard height to fix android keyboard switching Pull Request resolved: facebook#34749 Test Plan: With simple code: ```jsx import { StatusBar } from "expo-status-bar"; import React from "react"; import { KeyboardAvoidingView, StyleSheet, Text, TextInput, View, } from "react-native"; export default function App() { return ( <KeyboardAvoidingView style={styles.container} behavior="height"> <Text>Open up App.js to start working on your app!</Text> <StatusBar style="auto" /> <TextInput style={{ backgroundColor: "red", width: "100%" }} /> </KeyboardAvoidingView> ); } const styles = StyleSheet.create({ container: { padding: 32, flex: 1, backgroundColor: "#fff", alignItems: "center", justifyContent: "space-between", }, }); ``` Notice the consistency of the TextInput after the changes, while before it would just move around more you switch the keyboards. | Before | After | |---|---| | ![2022-09-21 13-59-09 2022-09-21 14_01_44](https://user-images.githubusercontent.com/3984319/191499509-b41280a0-2969-4fe6-8796-c5695b999f27.gif) | ![2022-09-21 14-03-33 2022-09-21 14_04_30](https://user-images.githubusercontent.com/3984319/191499628-a5832b88-e511-448d-8081-ac48d3a3690a.gif) | Reviewed By: cipolleschi Differential Revision: D39718812 Pulled By: NickGerleman fbshipit-source-id: 2550182e846f3f8e719d727fa8e6d87165faebf6
Summary
Currently, height is sometimes the only valid option for pushing
TextInput
up in the layout on Android. The problem is when switching keyboards. For instance, switching from ABC to emojis. This will trigger keyboard show events and recalculate the height for theKeyboardAvoidingView
. Since the keyboard is still showing, the view has the height that was previously calculated and thusframe
represents that. This means theframe.height
has adjustments for the keyboard calculated in it, but it is used the same way as if the keyboard was not showing. This results in wrong calculation and the input showing at the incorrect place in the layout (mostly hidden under the keyboard)This fix simply uses the previous calculation to offset
frame.height
, resulting in the correct height and smooth switching between keyboards. It's also scoped only to height mode since that's where the problem shows.Note: I mention android here, but it fixes it for both platforms. It's just that iOS usually works best with different behaviour so it's rarely used there.
Changelog
[General] [Added] - Include
this.state.bottom
when calculating new keyboard height to fix android keyboard switchingTest Plan
With simple code:
Notice the consistency of the TextInput after the changes, while before it would just move around more you switch the keyboards.