KeyboardAvoidingView collapses to 0 height on iOS14 when "Prefer Cross-Fade Transitions" is enabled #31484
Labels
Comments
|
The bug can be repro'd with the KeyboardAvoidingView example: |
|
This also seems to happen with an inverted FlatList when the keyboard closes. |
|
Apologies for closing the original issue, it was a mistake. I thought it had been resolved in React Native 0.64.x but I still had a workaround patch in place. It has been reopened. I suspect the patch that @sterlingwes suggested still works: #29974 (comment) |
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 9, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until RN starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 9, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until Facebook starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 9, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until Facebook starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 9, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until Facebook starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 9, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until Facebook starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Dec 10, 2021
…ngView The immediate catalyst for this is zulip#5162, but I've had earlier encounters with React Native's KeyboardAvoidingView, and I don't love it. See - our 70eca07; that took a lot of painstaking investigation that would have been unnecessary if `keyboardVerticalOffset` had had a clear design from the beginning - the implementation, at https://github.com/facebook/react-native/blob/v0.64.2/Libraries/Components/Keyboard/KeyboardAvoidingView.js - the long list of open issues in RN that mention it: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+KeyboardAvoidingView including these two, which raise the same issue as zulip#5162 and haven't been resolved: facebook/react-native#29974 facebook/react-native#31484 (patch-package isn't a resolution) I'm not optimistic that we can get zulip#5162 fixed in bounded time unless we abandon KeyboardAvoidingView and implement the necessary logic ourselves. Fortunately, that seems pretty doable. I don't yet see a quick fix in KeyboardAvoidingView that doesn't risk making its code even more brittle and hard to reason about. My threshold for that is pretty low in this case: with the code in its current state, each additional piece of logic (even sound logic) comes with an unusually large cost of understanding/maintaining it. My current understanding is that the initial setup for maintaining our own react-native fork would be kind of a big project, but I could be wrong. None of my PRs to React Native can be accepted until Facebook starts checking its CLA-related mail; I should be covered by the corporate CLA signed by Kandra. See, e.g., facebook/react-native#29926 (comment) . RN upgrades tend to take a while for us to do; see our most recent, to RN v0.64: zulip#4426. RN v0.67 is already doing release candidates. Tested on my iPhone 13 Pro running iOS 15, with and without the "Prefer Cross-Fade Transitions" setting (for the sake of zulip#5162). Fixes: zulip#5162
This was referenced Feb 17, 2022
1 task
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 25, 2022
…ityInfo (#34406) Summary: This PR adds `prefersCrossFadeTransitions()` to AccessibilityInfo in order to add support for "Prefer Cross-Fade Transitions", exposing the iOS settings option as proposed here react-native-community/discussions-and-proposals#452. I believe this would be especially helpful for solving #31484 #### TODO - [ ] Submit react-native-web PR updating AccessibilityInfo documentation. ## Changelog [iOS] [Added] - Add support for "Prefer Cross-Fade Transitions" into AccessibilityInfo Pull Request resolved: #34406 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the Accessibility page https://user-images.githubusercontent.com/11707729/154588402-7d050858-3c2d-4d86-9585-928b8c66941b.mov Reviewed By: cipolleschi Differential Revision: D38711316 Pulled By: makovkastar fbshipit-source-id: b9965cd4285f1aa0f1fa927080370a22329c2f62
dmytrorykun
pushed a commit
that referenced
this issue
Sep 14, 2022
… is enabled (#34503) Summary: Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled and unfortunelly there isn't much we can do on the native side to fix it. Closes #31484 Closes #29974 [iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled Pull Request resolved: #34503 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the KeyboardAvoidingView page 3. Focus and blur inputs and observe the keyboard behaving correctly https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov Reviewed By: jacdebug Differential Revision: D39055213 Pulled By: cipolleschi fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f
kelset
pushed a commit
that referenced
this issue
Oct 3, 2022
…ityInfo (#34406) Summary: This PR adds `prefersCrossFadeTransitions()` to AccessibilityInfo in order to add support for "Prefer Cross-Fade Transitions", exposing the iOS settings option as proposed here react-native-community/discussions-and-proposals#452. I believe this would be especially helpful for solving #31484 #### TODO - [ ] Submit react-native-web PR updating AccessibilityInfo documentation. ## Changelog [iOS] [Added] - Add support for "Prefer Cross-Fade Transitions" into AccessibilityInfo Pull Request resolved: #34406 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the Accessibility page https://user-images.githubusercontent.com/11707729/154588402-7d050858-3c2d-4d86-9585-928b8c66941b.mov Reviewed By: cipolleschi Differential Revision: D38711316 Pulled By: makovkastar fbshipit-source-id: b9965cd4285f1aa0f1fa927080370a22329c2f62
kelset
pushed a commit
that referenced
this issue
Oct 3, 2022
… is enabled (#34503) Summary: Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled and unfortunelly there isn't much we can do on the native side to fix it. Closes #31484 Closes #29974 ## Changelog [iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled Pull Request resolved: #34503 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the KeyboardAvoidingView page 3. Focus and blur inputs and observe the keyboard behaving correctly https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov Reviewed By: jacdebug Differential Revision: D39055213 Pulled By: cipolleschi fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f
alphatrl
pushed a commit
to taskade/react-native
that referenced
this issue
Oct 17, 2022
… is enabled (facebook#34503) Summary: Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled and unfortunelly there isn't much we can do on the native side to fix it. Closes facebook#31484 Closes facebook#29974 ## Changelog [iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled Pull Request resolved: facebook#34503 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the KeyboardAvoidingView page 3. Focus and blur inputs and observe the keyboard behaving correctly https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov Reviewed By: jacdebug Differential Revision: D39055213 Pulled By: cipolleschi fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f # Conflicts: # Libraries/Components/Keyboard/KeyboardAvoidingView.js
alphatrl
pushed a commit
to taskade/react-native
that referenced
this issue
Oct 17, 2022
… is enabled (facebook#34503) Summary: Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled and unfortunelly there isn't much we can do on the native side to fix it. Closes facebook#31484 Closes facebook#29974 ## Changelog [iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled Pull Request resolved: facebook#34503 Test Plan: **On iOS 14+** 1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions". 2. Open the RNTester app and navigate to the KeyboardAvoidingView page 3. Focus and blur inputs and observe the keyboard behaving correctly https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov Reviewed By: jacdebug Differential Revision: D39055213 Pulled By: cipolleschi fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f # Conflicts: # Libraries/Components/Keyboard/KeyboardAvoidingView.js
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a copy-paste from another issue that the OP closed without it being resolved.
Description
For users with Prefer Cross-Fade Transitions enabled in their Accessibility > Motion options on iOS 14 KeyboardAvoidingView will collapse to 0px in height when the keyboard hides (when an input is blurred).
The KeyboardAvoidingView behaves correctly when Prefer Cross-Fade Transitions is switched off.
The issue appears to be caused by incorrect endCoordinates coming back from the Keyboard.addListener('keyboardWillChangeFrame') listener in KeyboardAvoidingView as the values that come back differ significantly depending on the status of Prefer Cross-Fade Transitions.
This behaviour happens with behaviour set to height, padding and margin and doesn't appear to be an issue with the KeyboardAvoidingView directly but just the Keyboard events.
React Native version:
Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.
Expected Results
The KeyboardAvoidingView should reset to its normal height.
Snack, code example, screenshot, or link to a repository:
See linked issue: #29974
The text was updated successfully, but these errors were encountered: