[Android]: append TextInput inside ScrollView doesn't always scroll correctly to the new Item
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 127k
- Forks
- 25.3k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 4
Description
Description
On android only, when user add a new TextInput inside a ScrollView, the scrollview is expected to scroll to the new added TextInput. It doesn't always work on android.
Note: I don't know the exact reproduction conditions, but it seems that the added item should be outside of the visible screen.
Steps to reproduce
Create a sample app with a list of inside a .
You should be able to append a new with a button to reproduce the issue.
When a new is added I expect the ScrollView scroll to the newly added
On android this is randomly working. On iOS, It always works.
I had the issue originally on 0.79, but I reproduce it on a react-native only sample on 0.81.0 (see linked repo)
Here is an extract of JSX code:
<ScrollView>
<!-- Append a new TextInput -->
<Pressable onPress={() => {
setCount(c => c + 1);
}}>
<Text>Press me</Text>
</Pressable>
<!-- display a list of textInput -->
{Array.from({length: count}).map((_, i) => (
<TextInput
style={{ height:50 }}
key={i}
autoFocus={i === count - 1}> <!-- ensure only the last item added has autofocus (this is also reproduced if autoFocus={true} )-->
Item {i + 1}
</TextInput>
))}
</ScrollView>
React Native Version
0.81.0, but also 0.79.1
Affected Platforms
Runtime - Android
Output of npx @react-native-community/cli info
System:
OS: macOS 15.0
CPU: (11) arm64 Apple M3 Pro
Memory: 102.78 MB / 18.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 20.18.1
path: ~/.nvm/versions/node/v20.18.1/bin/node
Yarn:
version: 1.22.22
path: /opt/homebrew/bin/yarn
npm:
version: 10.8.2
path: ~/.nvm/versions/node/v20.18.1/bin/npm
Watchman:
version: 2025.06.30.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 24.2
- iOS 18.2
- macOS 15.2
- tvOS 18.2
- visionOS 2.2
- watchOS 11.2
Android SDK:
API Levels:
- "28"
- "33"
- "34"
- "35"
- "36"
Build Tools:
- 26.0.3
- 30.0.3
- 33.0.0
- 33.0.1
- 34.0.0
- 35.0.0
- 36.0.0
System Images:
- android-30 | Google APIs ARM 64 v8a
- android-30 | Google Play ARM 64 v8a
- android-34 | Google APIs ARM 64 v8a
- android-35 | Google Play ARM 64 v8a
Android NDK: 26.1.10909125
IDEs:
Android Studio: 2025.1 AI-251.25410.109.2511.13665796
Xcode:
version: 16.2/16C5032a
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.12
path: /usr/bin/javac
Ruby:
version: 2.6.10
path: /usr/bin/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.0.0
wanted: 20.0.0
react:
installed: 19.1.0
wanted: 19.1.0
react-native:
installed: 0.81.0
wanted: 0.81.0
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: false
Stacktrace or Logs
N/A
MANDATORY Reproducer
https://github.com/freeboub/bug-react-native-Append-TextInput-In-ScrollView
Screenshots and Videos
You can see that the last added TextInput doesn't correctly focus on last item:
https://github.com/user-attachments/assets/4b23a365-fe57-4dfb-8862-315f27132d22
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the mandatory reproducer at github.com/freeboub/bug-react-native-Append-TextInput-In-ScrollView and run the provided ScrollView, Pressable, and TextInput example on Android 0.81.0. Compare the focus and scroll behavior with iOS and determine the conditions under which the newly appended, off-screen TextInput is not reached; done means the behavior is reliably correct on Android.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, react-native
- Domain
- mobile
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100