Repository navigation
Fix modal focus trapping for elements excluded from tab order - #2864
Open
huytdps13400 wants to merge 1 commit into
Open
huytdps13400 wants to merge 1 commit into
huytdps13400 wants to merge 1 commit into
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 6f9902f:
|
huytdps13400
force-pushed
the
fix/modal-reverse-focus
branch
from
October 5, 2026 06:54
510d3ce to
6f9902f
Compare
This branch has not been deployed
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.
When a modal contains a ScrollView with
focusable={false}ortabIndex={-1}, reverse keyboard navigation can get stuck on the scroll container. The trap calls.focus()on candidates, which succeeds even for elements explicitly excluded from the tab order. Its first/last focus comparison therefore never reaches the buttons inside the scroll view.Skip candidates with an explicit negative
tabindexwhen choosing a focus-trap destination, while continuing to search their descendants. This also avoids selecting excluded buttons at the edges of a modal. Explicit programmatic focus inside the modal remains allowed, and the existing trap fallback still handles content with no eligible descendants.Fixes #2823 for the reported
focusable={false}/tabIndex={-1}configuration.Validation
spawnerror −86. Flow checking is unverified locally.The browser can also programmatically focus a scroll container with no explicit tabindex. That existing behavior remains unchanged; this patch specifically honors elements explicitly excluded from the tab order.