[chocky335]

Summary:

A disabled Android ReactEditText calls requestDisallowInterceptTouchEvent(true) on DOWN before its superclass checks isEnabled. A native parent can then cancel its gesture and lose the press. This affects RNGH Touchable and the default RNGH Pressable around a non-editable RN TextInput inside a ScrollView.

Return false before the touch and interception logic when the native view is disabled. Enabled inputs keep the existing path. The tests cover disabled DOWN/MOVE/UP/CANCEL events, re-enabling the same input, and disabling it during an active gesture. If an input becomes disabled during a gesture, it releases its interception request so the parent can handle scrolling.

Related: software-mansion/react-native-gesture-handler#4622.

The guard checks native isEnabled. #59156 proposes keeping non-editable inputs enabled and selectable. If that lands, editable={false} alone would no longer trigger this guard. Disabled inputs would still use it. Parent-press behavior for read-only, selectable inputs needs a separate decision.

Changelog:

[ANDROID] [FIXED] - Prevent disabled TextInput views from consuming native touches or blocking ancestor touch interception.

Test Plan:

On main commit 79a562960dbe5de3b99a2ca4531acc8dab620c0e, the new test fails against the unmodified source because disabled touch returns true. The mid-gesture regression test also fails against commit 8a1211c685bca0950e03f73f7ea48f9a953ca506, before the interception-release fix. With both fixes, the complete ReactAndroid JVM suite passes: 781 tests, zero failures, errors, or skips. This includes all 30 TextInput property tests.

# Before the fix: one regression test fails as expected.
./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest \
  --tests com.facebook.react.views.textinput.ReactTextInputPropertyTest.testDisabledInputDoesNotClaimNativeTouches \
  -Preact.internal.useHermesStable=true --no-daemon --max-workers=2 \
  '-Dorg.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=768m -Djava.net.preferIPv4Stack=true' --console=plain

# Before the interception-release fix: the new regression test fails as expected.
./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest \
  --tests com.facebook.react.views.textinput.ReactTextInputPropertyTest.testDisablingInputDuringGestureAllowsParentInterception \
  -Preact.internal.useHermesStable=true --no-daemon --max-workers=2 \
  '-Dorg.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=768m -Djava.net.preferIPv4Stack=true' --console=plain

# After both fixes: all 781 tests pass.
./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest \
  -Preact.internal.useHermesStable=true --no-daemon --max-workers=2 \
  '-Dorg.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=768m -Djava.net.preferIPv4Stack=true' --console=plain

node scripts/format-kotlin.js --check
git diff --check

Kotlin formatting and whitespace checks pass. The test build used JDK 21, the Android SDK, and pinned Yarn 1.22.22 on PATH. Dependencies were installed and codegen was built first.

The device builds contained the original disabled-input guard. The interception-release fix has JVM test coverage only.

The device comparison used Xiaomi 23046RP50C, Android 14, RN 0.88.0, and RNGH 40ac2067a98d1b6cec23bb0efeac9454cc4ab76c. With a ScrollView ancestor, one tap per disabled input produced RN/RNGH Pressable/RNGH Touchable counts of 1/0/0 on stock RN. The same check produced 1/1/1 with the guard. Without a ScrollView, both builds produced 1/1/1. The pointer-events wrapper control worked in both builds. The candidate preserved editable focus in ScrollView, repeat taps, long-press callbacks, and drag cancellation.

The device comparison used a ReactEditText subclass with this guard against the published RN 0.88 AAR, not a source-built current-main APK. Exact RN 0.86.3 and fling-stop behavior remain untested. Outside ScrollView, editable inputs triggered the parent instead of focusing in both builds. Scrcpy mouse events also differed in both builds, so all reported tap checks used touchscreen-source events.

Reproduction, diagnostic harness, and before/after screenshots.

[meta-cla]

Hi @chocky335!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!