[Android][Fabric] Fatal "Cannot remove child at index" — focus re-request inside ViewGroup.removeViewInternal throws "descendant of this view" during Fabric removal (0.86.0) #57862

Activity

1. react-native-bot

   added

   Needs: Author Feedback

   Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.This issue could be improved with a clear list of steps to reproduce the issue.

   on Aug 7, 2026
2. react-native-bot commented on Aug 7, 2026

   

   react-native-bot

   on Aug 7, 2026

   Collaborator

   More actions

   Warning

   Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:
   

   • For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
   • If your bug is UI related: a Snack
   • If your bug is build/upgrade related: a project using our Reproducer Template

   
   You can read more about about it on our website: How to report a bug.
3. chengjwk commented on Aug 14, 2026

   

   chengjwk

   on Aug 14, 2026

   Author

   More actions

   Following up with the full mechanism, plus the precondition that I think explains why this is hard to reproduce — and a candidate Playground repro built from it.

   The IAE is thrown by the framework during a focus re-request, not by RN

   ViewGroup.removeViewInternal detaches the child before calling rootViewRequestFocus(). If the removed child (or a descendant) held input focus, that focus re-request fires an accessibility event whose tree walk sorts children via offsetDescendantRectToMyCoords — while the just-detached child is still mid-removal:

   ReactClippingViewManager.removeViewAt        (RN — clipping-disabled branch)
     ViewGroup.removeViewAt → ViewGroup.removeViewInternal
       View.rootViewRequestFocus → requestFocus → onRequestFocusInDescendants
         → handleFocusGainInternal → onFocusChanged → sendAccessibilityEvent
           → dispatchPopulateAccessibilityEventInternal   (deep recursion)
             → ViewGroup$ChildListForAccessibility.obtain
               → ViewGroup$ViewLocationHolder.init
                 → offsetDescendantRectToMyCoords
                   → IllegalArgumentException: parameter must be a descendant of this view
   

   Why it surfaces as a fatal IllegalStateException

   The throw is synchronous inside the Fabric mount item, so it propagates into SurfaceMountingManager.removeViewAt's catch (e: RuntimeException) (v0.86.0, SurfaceMountingManager.kt:505) and is rethrown as IllegalStateException("Cannot remove child at index … only N children in parent") (:526).

   Three notes that may help triaging other reports of this ISE:

   • The ISE message identifies nothing. That catch wraps any RuntimeException from the removal, so the message is the same regardless of root cause. The Caused by: is the only discriminator.
   • only 0 children is expected here, not evidence against this diagnosis. removeViewInternal has already detached the child (count → 0) by the time the IAE fires, so RN's fallback count legitimately reports 0.
   • The cause is not in the AndroidRuntime FATAL block. It crosses JNI as com.facebook.jni.CppException: Exception in HostFunction, which flattens it; the Caused by: is logged separately by MountItemDispatcher. This is probably why many reports of this ISE arrive with no cause attached.

   Why #56182 doesn't cover this

   #56182 added a try/catch for this exact IAE, but only on addChildrenForAccessibility. I checked the source on both tags: v0.86.0 (ReactViewGroup.kt:1003, message check at :1072) and 0.87-stable (:989 / :1058). In both, that is still the only guarded method — there is no removeView* / removeViewsInLayout override. So the removal path is unguarded in 0.87.0 as well.

   Counterfactual evidence that the removal path is the right level to guard

   We inject an override of ReactViewGroup.removeViewAt via AGP bytecode instrumentation (same mechanism as the transform in #57800), wrapping only the super.removeViewAt(index) call in a catch for IllegalArgumentException whose message contains descendant of this view, and rethrowing anything else.

   With it in place, the IAE is intercepted one frame below SurfaceMountingManager's catch: the fatal ISE never occurs, the process survives, and the view hierarchy is intact afterwards (no missing or corrupted views from the swallowed removal). Without it, the same interaction is fatal. Mirroring #56182 onto the removal methods should be sufficient.

   Candidate reproducer — and the precondition I think was missing

   View.sendAccessibilityEvent is a no-op unless an accessibility service is running. With no a11y service enabled, this bug cannot fire at all, which I suspect is why it doesn't show up in ordinary testing. Preconditions I believe are necessary:

   1. An accessibility service enabled (e.g. TalkBack)
   2. The view being removed, or a descendant, holds input focus at removal time
   3. The removal dispatched through Fabric's mount path
   4. Removal via ViewGroup.removeViewAt — i.e. removeClippedSubviews disabled; the clipping branch takes removeViewWithSubviewClippingEnabled instead (ReactClippingViewManager.kt:58-65)

   Playground sketch:

   const [show, setShow] = React.useState(true);
   return (
     <View>
       <Button title="unmount" onPress={() => setShow(false)} />
       {show ? (
         <View>
           <TextInput autoFocus />
         </View>
       ) : null}
     </View>
   );

   With TalkBack enabled, focus the TextInput, then unmount the subtree.

   To be clear about the status: this snippet is untested — I'm posting the mechanism and the a11y-service precondition now in case that is enough for someone to confirm faster than I can. In our app the crash reproduces readily under real manual interaction but not under scripted adb shell input, so the timing seems to depend on genuine focus/a11y-event interleaving. If I can make it deterministic I'll open a Playground PR as the formal reproducer.

   Environment

   • React Native 0.86.0, New Architecture (Fabric + bridgeless), Hermes
   • Pixel 9 Pro, Android 17
   • Verified still unguarded in source at 0.87-stable / 0.87.0

   — drafted by Claude (AI)
4. github-actions

   added

   Needs: AttentionIssues where the author has responded to feedback.Issues where the author has responded to feedback.

   and removed

   Needs: Author Feedback

   on Aug 14, 2026
5. chengjwk commented on Aug 14, 2026

   

   chengjwk

   on Aug 14, 2026

   Author

   More actions

   Update: the candidate reproducer above does not fire. Built it as a standalone RN 0.86.0 app (Fabric, bridgeless, Hermes, release build; Pixel 9 Pro / Android 17) and drove ~800 timer-driven unmounts of a focused subtree, sweeping:

   • focused TextInput inside the removed subtree, with a focusable sibling surviving outside it
   • a sibling-rich parent (15 accessible children, removal at a middle index) so the ChildListForAccessibility → ViewLocationHolder sibling sort is actually reachable
   • removals scheduled through reanimated's exit-animation path (remount before the exit finishes, so the withheld Remove replays against a changed hierarchy)
   • concurrent externally-forced a11y tree traversals (uiautomator dump in a loop) with accessibility services enabled

   Zero IAEs, zero fatals. So the preconditions in my previous comment are necessary but evidently not sufficient. One caveat: TalkBack itself was not running — the enabled services subscribe only to TYPE_WINDOW_STATE_CHANGED. But in the app where this crashes readily, guard hits occur with exactly those services enabled, so a broader-subscription service is not required there.

   The clearest structural difference in the reproducing app: the crashing parent's ancestor chain runs through fragment-backed screen containers (react-native-screens: ScreenContentWrapper → Screen → ScreenStack), with removals arriving around navigation transitions. Possibly relevant to that: ScreenStackViewManager.getChildCount returns the fragment count while SurfaceMountingManager's fallback scan uses the raw childCount, so the two can disagree during teardown.

   Next step on my side: instrumenting the guarded build to dump the exact hierarchy (parent class, child count/classes, ancestor chain, focus holder) at the instant the IAE is caught, then minimizing from a known-crashing configuration instead of building up from a blank app. Will report back.

   — drafted by Claude (AI)