Repository navigation
fix: OverKeyboardView crash with a11y - #962
Merged
Merged
Conversation
Contributor
📊 Package size report
|
kirillzyusko
added
🎯 crash
kirillzyusko
changed the title
OverKeyboardView crash with a11yOverKeyboardView crash with a11y
meta-codesync Bot
pushed a commit
to react/react-native
that referenced
this pull request
Apr 2, 2026
Summary: Guard `ReactViewGroup.addChildrenForAccessibility` against transient non-descendant races during accessibility traversal on Android. This replaces direct `super.addChildrenForAccessibility(...)` calls with a small wrapper that: - catches `IllegalArgumentException` - only swallows the specific "descendant of this view" case - rethrows all other `IllegalArgumentException`s ## Why There are recurring crashes with stack traces ending in: `ViewGroup.offsetRectBetweenParentAndChild` -> `offsetDescendantRectToMyCoords` -> `addChildrenForAccessibility` -> `IllegalArgumentException: parameter must be a descendant of this view`. This can happen when accessibility is traversing children while views are being re-parented/removed. Related reports: - #32649 - #38925 - #7377 - kirillzyusko/react-native-keyboard-controller#961 - kirillzyusko/react-native-keyboard-controller#962 - dotnet/maui#32927 There is also precedent in RN for handling this class of non-descendant race defensively: - #55273 ## Scope This is intentionally minimal and localized to accessibility child collection in `ReactViewGroup`. Behavior is unchanged in the non-racy path. ## Changelog: [Android] [Fixed] - Guard `ReactViewGroup.addChildrenForAccessibility` against transient non-descendant accessibility traversal crashes. Pull Request resolved: #56182 Test Plan: Validated in a downstream RN Android app on Android 16 with repeated sheet/modal open-close stress and active accessibility hierarchy traversal; crash reproduces before patch and no longer reproduces with this guard. Reviewed By: jorge-cab Differential Revision: D97861147 Pulled By: Abbondanzo fbshipit-source-id: 15e624a94d5acd99777a7426787b52d8e85cdf8a
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Description
Fixed a crash when
TalkBackis enabled on Android and you useOverKeyboardView.💡 Motivation and Context
The problem comes from the fact that the system tries to traverse the view hierarchy, but overlay views are not part of the main view hierarchy.
OverKeyboardHostViewpretends that the views you pass to it are its own children. From the platform’s point of view those views are not really descendants ofOverKeyboardHostView— they live in a completely different window created withWindowManager.addView.When the Android accessibility framework walks the view-tree it calls
addChildrenForAccessibility(), iterates overgetChildAt(i)and finally calls:That helper checks that child is a true descendant of parent, and if it isn’t it throws the exception you see:
To solve this I decided to exclude
OverKeyboardHostViewfrom accessibility traversal, so that inner views handles accessibility on their own (this is how it should work).Closes #961
📢 Changelog
Android
OverKeyboardViewcontainer to an accessibility;🤔 How Has This Been Tested?
Tested manually in Fabric example on Pixel 7 Pro API 35.
📸 Screenshots (if appropriate):
telegram-cloud-document-2-5323756428911999326.mp4
📝 Checklist