Description
After upgrading from 2.31.1 to 3.0.2 (also happens on 3.1.0), our app crashes with SIGABRT the first time a screen with a Pressable inside a ScrollView mounts. No interaction needed — it crashes on the very first layout pass.
The assertion is in RNGestureHandlerDetectorShadowNode.cpp:
react_native_assert(
!children.empty() &&
"GestureDetector must have at least one child node.");
We only saw this once the Pressable was nested inside a ScrollView, which was itself inside a react-native-screens screen (RNSScreen). A plain Pressable with no such nesting did not crash for us.
I confirmed this assertion is unchanged on current main as of this report (identical to the code shipped in 3.0.2), so this doesn't look fixed yet. It was introduced by #3981, which relaxed the previous children.size() == 1 assertion to !children.empty() to support multi-child detectors — but doesn't appear to guard against the detector receiving zero children during layout, which is what we're hitting.
Steps to reproduce
- Put a
Pressable (from react-native-gesture-handler) inside a ScrollView.
- Put that
ScrollView inside a screen managed by react-native-screens (e.g. any React Navigation native-stack or Expo Router screen).
- Launch the app and navigate to that screen — no tap or scroll required.
Reproduction
We don't have a minimal Snack/repo isolated yet — happy to put one together if it would help triage. The crash reproduces reliably (2/2 cold launches) in our Expo Router app under the conditions above.
Crash log
Exception Type: EXC_CRASH (SIGABRT)
Triggered by Thread: com.facebook.react.runtime.JavaScript
abort
__assert_rtn
YogaLayoutableShadowNode::layout (YogaLayoutableShadowNode.cpp:709)
YogaLayoutableShadowNode::layout (YogaLayoutableShadowNode.cpp:732)
RNGestureHandlerDetectorShadowNode::layout (RNGestureHandlerDetectorShadowNode.cpp:73)
... (repeats) ...
ScrollViewShadowNode::layout (ScrollViewShadowNode.cpp:62)
... (repeats) ...
RNSScreenShadowNode::layout (RNSScreenShadowNode.cpp:122)
... (repeats) ...
YogaLayoutableShadowNode::layoutTree (YogaLayoutableShadowNode.cpp:674)
Reproduced identically on two separate cold launches.
Gesture Handler version
3.0.2 (also reproduces on 3.1.0)
React Native version
0.85.3
Platforms
iOS
JavaScript runtime
Hermes
Workflow
Using Expo Prebuild or an Expo development build
Architecture
New Architecture (Fabric)
Build type
Debug mode
Device
iOS simulator
Acknowledgements
Yes
Description
After upgrading from
2.31.1to3.0.2(also happens on3.1.0), our app crashes withSIGABRTthe first time a screen with aPressableinside aScrollViewmounts. No interaction needed — it crashes on the very first layout pass.The assertion is in
RNGestureHandlerDetectorShadowNode.cpp:react_native_assert( !children.empty() && "GestureDetector must have at least one child node.");We only saw this once the
Pressablewas nested inside aScrollView, which was itself inside areact-native-screensscreen (RNSScreen). A plainPressablewith no such nesting did not crash for us.I confirmed this assertion is unchanged on current
mainas of this report (identical to the code shipped in3.0.2), so this doesn't look fixed yet. It was introduced by #3981, which relaxed the previouschildren.size() == 1assertion to!children.empty()to support multi-child detectors — but doesn't appear to guard against the detector receiving zero children during layout, which is what we're hitting.Steps to reproduce
Pressable(fromreact-native-gesture-handler) inside aScrollView.ScrollViewinside a screen managed byreact-native-screens(e.g. any React Navigation native-stack or Expo Router screen).Reproduction
We don't have a minimal Snack/repo isolated yet — happy to put one together if it would help triage. The crash reproduces reliably (2/2 cold launches) in our Expo Router app under the conditions above.
Crash log
Reproduced identically on two separate cold launches.
Gesture Handler version
3.0.2 (also reproduces on 3.1.0)
React Native version
0.85.3
Platforms
iOS
JavaScript runtime
Hermes
Workflow
Using Expo Prebuild or an Expo development build
Architecture
New Architecture (Fabric)
Build type
Debug mode
Device
iOS simulator
Acknowledgements
Yes