[Android][0.84.1] TouchableOpacity only receives onPress on text area after disabled-to-enabled transition
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 127k
- Forks
- 25.3k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 4
Description
Description
TouchableOpacity only receives onPress on text area after disabled-to-enabled transition
Description
After upgrading from React Native 0.81.3 to 0.84.1, in one custom button component (TouchableOpacity enabled only when disabled is false), button becomes partially non-interactive on Android.
The button works as expected when initially disabled.
After filling inputs and the button becomes enabled, only the <Text> area inside the button is clickable.
The rest of the button area (left/right empty space / padded area) does not trigger onPress.
This did not happen in RN 0.81.3.
I could not reproduce this behavior in Expo Snack. This appears to be tied to our native app codepath in 0.84.1.
Expected behavior:
Full button area should be tappable when enabled (same as 0.81.3), not just text area.
Actual behavior:
After enabled state transition, tap target is reduced to the text node area.
Affected Platforms
Android (emulator and physical device).
Steps to reproduce
Steps to reproduce
- Render a button that conditionally renders:
- disabled/loading:
<View ...>{...button content...}</View> - enabled:
<TouchableOpacity ...>{...same content...}</TouchableOpacity>
- disabled/loading:
- Include non-text areas in content (for example
leftComponentand/orrightComponent), not only text. - Start with disabled = true.
- Enter input values so button becomes enabled.
- On Android, tap multiple times on text area and on left/right empty areas.
- Observe: only text area fires
onPress, non-text areas do not.
React Native Version
0.84.1
Affected Platforms
Runtime - Android
Output of npx @react-native-community/cli info
System:
OS: macOS 26.4.1
CPU: (11) arm64 Apple M3 Pro
Memory: 426.92 MB / 36.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 25.9.0
path: ~/.nvm/versions/node/v25.9.0/bin/node
Yarn:
version: 1.22.22
path: /opt/homebrew/bin/yarn
npm:
version: 11.12.1
path: ~/.nvm/versions/node/v25.9.0/bin/npm
Watchman:
version: 2024.12.02.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: /Users/--/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 25.2
- iOS 26.2
- macOS 26.2
- tvOS 26.2
- visionOS 26.2
- watchOS 26.2
Android SDK:
API Levels:
- "28"
- "31"
- "35"
- "36"
Build Tools:
- 30.0.2
- 34.0.0
- 35.0.0
- 36.0.0
System Images:
- android-33 | Google Play ARM 64 v8a
- android-35 | Google APIs ARM 64 v8a
- android-35 | Google Play ARM 64 v8a
- android-36 | Google Play ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2025.3 AI-253.32098.37.2534.15336583
Xcode:
version: 26.2/17C52
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.12
path: /usr/bin/javac
Ruby:
version: 2.7.5
path: /Users/--/.rbenv/shims/ruby
npmPackages:
"@react-native-community/cli":
installed: 20.1.0
wanted: 20.1.0
react:
installed: 19.2.3
wanted: 19.2.3
react-native:
installed: 0.84.1
wanted: 0.84.1
react-native-macos: Not Found
npmGlobalPackages:
"*react-native*": Not Found
Android:
hermesEnabled: true
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true
Stacktrace or Logs
No crash. No stacktrace. Pure touch/interaction issue.
MANDATORY Reproducer
https://snack.expo.dev/@zehragunes/awkward-orange-soylent
Screenshots and Videos
https://github.com/user-attachments/assets/4749df92-3ae6-4a00-abec-3022b286b8e6
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 TouchableOpacity Android touch-handling path and reproduce the disabled-to-enabled transition using the component pattern and mandatory Expo Snack linked in the issue. Compare behavior between React Native 0.81.3 and 0.84.1, including taps on text and padded left/right areas; done means the full enabled button area triggers onPress.
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
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100