Focus trap lost when you click an item and remove it
See original GitHub issueBug report
Current Behavior
If you click an item and remove it, the focus gets set to the browser’s Url bar.
When you tab back into the body content, you can tab to elements that are behind the focus trap.
Expected behavior
Focus shouldn’t go to the Url bar after removing an item.
If it does, you should return to the focus trap instead of elements outside it.
Reproducible example
Code: https://codesandbox.io/s/hardcore-stitch-ne0g0n?file=/App.js
Easier to reproduce fullscreen: https://ne0g0n.csb.app/
Additional context
Previously I’ve been using focus-trap-react and it didn’t have the same issue. Focus doesn’t go to the Url bar when items are removed, and if you manually focus the Url bar, you will return to the tab trap straight away.
Your environment
| Software | Name(s) | Version |
|---|---|---|
| Radix Package(s) | @radix-ui/react-dialog | 0.1.8-rc.48 |
| Radix Package(s) | @radix-ui/react-select | 0.1.2-rc.50 |
| React | n/a | latest |
| Browser | Chrome | 102.0.5005.115 |
| Operating System | Mac | 12.4 |
Issue Analytics
- State:
- Created a year ago
- Comments:7 (1 by maintainers)
Top Results From Across the Web
Using JavaScript to trap focus in an element | hidde.blog
Trapping focus is a behaviour we usually want when there is modality in a page. Components that could have been pages of their...
Read more >A CSS Approach to Trap Focus Inside of an Element
While experimenting, I discovered a neat CSS trick on how to trap focus within the element, a common accessibility requirement for modals, ...
Read more >Focus trap on <dialog> not absolute, focus escapes to ...
I find that when the dialog opens the focus does not completely "trap" like the ARIA modal example describes. They say when user...
Read more >How to trap focus inside modal to make it ADA compliant
If you have ever worked on any website which you want to make ADA compliant( which means the website should be entirely accessible...
Read more >Restoring ActiveElement Focus After A User-Interaction In ...
Yesterday, I looked at trapping focus within an element such that a user couldn't use keyboard-based navigation to tab outside of the given ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@jjenzz from my previous comment here: https://github.com/radix-ui/primitives/issues/1498#issuecomment-1177874105
So looks like in theory it might work because even though
focusoutis only raised by Chrome in these cases (when deleting the focused element) the next tab keeps it inside magically in the other browsers (I have no idea how they do that).However, I remember trying exactly what you did here from within
FocusScopebut had issues with distinguishing that case from other cases whererelatedTargetis alsonull.I’ll give it another spin soon.
This is an example in
Dialog.