fix: automatically detect top border of KeyboardAwareScrollView#1352
Merged
kirillzyusko merged 2 commits intomainfrom Mar 12, 2026
Merged
Conversation
kirillzyusko
added
🐛 bug
Contributor
📊 Package size report
|
kirillzyusko
force-pushed
the
fix/automatically-detect-top-border-of-keyboard-aware-scroll-view
branch
from
fb2e0d4 to
5d60c05
Compare
kirillzyusko
deleted the
fix/automatically-detect-top-border-of-keyboard-aware-scroll-view
branch
2 tasks
kirillzyusko
added a commit
that referenced
this pull request
Mar 18, 2026
## 📜 Description Silent `could not fing view for tag` warning for `KeyboardAwareScrollView` (similarly how it works for `KeyboardAvoidingView` now). ## 💡 Motivation and Context This issue got introduced after #1352 (which was based on #1346) In certain cases `onLayout` may be triggered but view may be not laid out yet (if you use it with `react-native-pager` lazy). Since changes in #1352 were purely additional (we try to understand the position of element on the screen, but before these changes we always assumed we were in the top of the screen) I decided to wrap it for now in `try/catch` block. Silenting error is not a correct fix, but this is the best what we can do now - we will not spam logs when devs update the package (in #1346 we also used `catch` block), but yes, in certain cases detection of top border will not work (and it didn't work before, so it's fair enough to silent the error). Closes #1375 ## 📢 Changelog <!-- High level overview of important changes --> <!-- For example: fixed status bar manipulation; added new types declarations; --> <!-- If your changes don't affect one of platform/language below - then remove this platform/language --> ### JS - handle rejected promises within `try/catch` block; ## 🤔 How Has This Been Tested? Tested via e2e tests, I didn't test changes manually because I don't have a repro. ## 📝 Checklist - [x] CI successfully passed - [x] I added new mocks and corresponding unit-tests if library API was changed
kirillzyusko
added a commit
that referenced
this pull request
Apr 27, 2026
## 📜 Description Fixed `IllegalViewOperationException` crash on Android. ## 💡 Motivation and Context Original code has been introduced in #1355 and further started to be used in #1352 Now if view is not found it throws an unhandled exception and crashes the app. In reality we already handle "view not found" exception, so we should just add a proper try/catch block to handle this error correctly in Kotlin code 🤞 Closes #1443 ## 📢 Changelog <!-- High level overview of important changes --> <!-- For example: fixed status bar manipulation; added new types declarations; --> <!-- If your changes don't affect one of platform/language below - then remove this platform/language --> ### Android - wrap `resolveView` with `catch (e: IllegalViewOperationException)`; ## 🤔 How Has This Been Tested? Tested via e2e pipeline. ## 📝 Checklist - [x] CI successfully passed - [x] I added new mocks and corresponding unit-tests if library API was changed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Description
Automatically detect top border of
KeyboardAwareScrollView.💡 Motivation and Context
Continue the epic with better discovery of component location on the screen and logical continuation of #1346
In this PR I started to detect relative position of
ScrollView, so that I better understand if caret is not visible because it obscured by other elements (header etc.) It's still not perfectly implemented and there is still a "blind"/"dead" zone where text is already hidden but scroll doesn't happen. I'll fix it in following PRs but for now I just want to bring these changes to upcoming1.21.0release 🤞We also can't use
measureInWindowbecause it produces incorrect measurements, so we need to use our custom implementation that has been added in #1355Significantly improves UI for behavior described in #1341
📢 Changelog
JS
KeyboardAwareScrollViewon the screen to better understand top border of the component relative to screen;🤔 How Has This Been Tested?
Tested manually on iPhone 17 Pro (iOS 26.2, simulator).
📸 Screenshots (if appropriate):
Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-03-10.at.19.43.33.mov
📝 Checklist