Repository navigation
[Android] Crash: NullPointerException in GestureHandler.isWithinBounds #4539
Description
Description
Production crash on Android. GestureHandler.isWithinBounds throws a NullPointerException when handle() passes a null coordinateView:
// GestureHandler.kt:689
fun isWithinBounds(view: View?, posX: Float, posY: Float): Boolean {
if (RNSVGHitTester.isSvgElement(view!!)) { // <- NPEcoordinateView is null when the handler's view is null. As far as I can tell, view is only set to null in reset().
GestureHandlerOrchestrator.deliverEventToGestureHandlers copies gestureHandlers into a list before dispatching. If handling the event for one handler causes another handler later in that list to be cancelled or reset, the later handler can still get into handle() with view == null. Nothing checks for null before the !!.
The same code is in 3.4.0-nightly-20260921-e26231e9d.
Stack trace
Fatal Exception: java.lang.NullPointerException:
at com.swmansion.gesturehandler.core.GestureHandler.isWithinBounds(GestureHandler.kt:689)
at com.swmansion.gesturehandler.core.GestureHandler.handle(GestureHandler.kt:410)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandler(GestureHandlerOrchestrator.kt:338)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandlers(GestureHandlerOrchestrator.kt:299)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.onTouchEvent(GestureHandlerOrchestrator.kt:76)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootHelper.dispatchTouchEvent(RNGestureHandlerRootHelper.kt:166)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootView.dispatchTouchEvent(RNGestureHandlerRootView.kt:62)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3171)
...
at com.xiaomi.mirror.MiuiMirrorImpl.isHandled(MiuiMirrorImpl.java:150)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:9965)
Steps to reproduce
I don't have a reliable repro. It shows up in Crashlytics from production users. I suspect it happens when a view with a gesture unmounts or its handler is dropped while a touch is still in progress, for example a bottom sheet or screen closing under the finger.
Suggested fix
In handle(), return early or cancel() when coordinateView is null. Alternatively, make isWithinBounds return false for a null view instead of using !!.
Environment
- react-native-gesture-handler: 3.3.0
- react-native: 0.87
- @swmansion/react-native-bottom-sheet: 0.16.2
- Platform: Android
- Device: Xiaomi (MIUI/HyperOS)
- Architecture: New Architecture (Fabric)
Steps to reproduce
Random in production.
A link to a Gist, an Expo Snack or a link to a repository based on this template that reproduces the bug.
https://description.provided.com
Gesture Handler version
3.3.0
React Native version
0.87
Platforms
Android
JavaScript runtime
Hermes
Workflow
React Native (without Expo)
Architecture
New Architecture (Fabric)
Build type
Release mode
Device
Real device
Device model
Xiaomi (MIUI/HyperOS)
Acknowledgements
Yes
Activity
github-actions commentedon Sep 23, 2026
Hey @faljabi! 👋
The issue doesn't seem to contain a minimal reproduction.
Could you provide a snack, a gist or a link to a GitHub repository that reproduces the problem?
github-actions commentedon Sep 23, 2026
Hey @faljabi! 👋
Some of the required information in this issue is missing, incomplete or invalid. Could you take another look at the template and make sure each of these is filled in with something we can act on?
package.jsonor lockfilepackage.jsonor lockfileOnce the issue is updated we will take another look. Thanks!
m-bert commentedon Sep 23, 2026
Hi @faljabi! Thank you for submitting this issue.
I have a question, do you use
GestureStateManagerin your code?faljabi commentedon Sep 23, 2026
Hi @m-bert, not at all. I used Pressable component only in one of the components.
Also, attached the full log from Firebase if it helps.
com.burgan.tijaratiapp_issue_8d65edb17a0ae9d17cc0838eef6a3ecb_crash_session_6AB3B6370028000168C61BEF52387AED_DNE_0_v2_stacktrace.txt
m-bert commentedon Sep 23, 2026
These logs seem to align with the crash I've seen with state manager. Maybe some other dependency is using it? It would be great if you could provide more information (like a code snippet), though I know it might be hard.
For now I can say that my crash was resolved by this change - you could try this as a patch. I won't merge this now as I'm waiting for other state manager changes, but I'll get back to this once they're finished.
Let me know if it's possible to see if these changes work.
m-bert commentedon Sep 23, 2026
Of course you might be right with the navigation case - I'm yet to check that
faljabi commentedon Sep 23, 2026
I will try the patch suggested. My issue it is not happening with me, it's happening at scale in production with 7 random users so far.
Will have this patch and will monitor on the next release.
m-bert commentedon Sep 28, 2026
Thank you @faljabi! Let me know how this experiment goes. I also have another, more general fix if it fails, though it treats symptoms, not cause.
I assume the other crash logs look similar, right? Or is there something that could help us?
faljabi commentedon Sep 30, 2026
Yes, all crash logs look similar! One thing I noticed, I crashes happening in different stack places as shown below:
Crashes group 1
Fatal Exception: java.lang.NullPointerException:
at com.swmansion.gesturehandler.core.GestureHandler.isWithinBounds(GestureHandler.kt:689)
at com.swmansion.gesturehandler.core.GestureHandler.handle(GestureHandler.kt:410)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandler(GestureHandlerOrchestrator.kt:338)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandlers(GestureHandlerOrchestrator.kt:299)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.onTouchEvent(GestureHandlerOrchestrator.kt:76)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootHelper.dispatchTouchEvent(RNGestureHandlerRootHelper.kt:166)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootView.dispatchTouchEvent(RNGestureHandlerRootView.kt:62)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3458)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:3076)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3458)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:3076)
Crashes group 2
Fatal Exception: java.lang.NullPointerException:
at com.swmansion.gesturehandler.core.GestureHandler.isWithinBounds(GestureHandler.kt:689)
at com.swmansion.gesturehandler.core.GestureHandler.handle(GestureHandler.kt:410)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandler(GestureHandlerOrchestrator.kt:338)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.deliverEventToGestureHandlers(GestureHandlerOrchestrator.kt:299)
at com.swmansion.gesturehandler.core.GestureHandlerOrchestrator.onTouchEvent(GestureHandlerOrchestrator.kt:76)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootHelper.dispatchTouchEvent(RNGestureHandlerRootHelper.kt:166)
at com.swmansion.gesturehandler.react.RNGestureHandlerRootView.dispatchTouchEvent(RNGestureHandlerRootView.kt:62)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3332)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2937)
at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3332)
at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2937)
They are almost identical, only diff highlighted in bold. Other crashes have also different stack lines but crash is the same.
m-bert commentedon Oct 1, 2026
Hi @faljabi!
If you're talking about the different line numbers in
ViewGroupthen I believe those are the result of different Android version. I think you should be able to confirm that in the tool itself (or in the full logs).Have you been able to check the patch I've sent you, or is it too early to say if it works?
[Android] Don't change state of handlers that haven't received any to…
faljabi commentedon Oct 1, 2026
Hi @m-bert, not yet as we need to have internal approvals before a new release.
Will let u know if we go public.