Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
FocusScope: If a focused element unmounts, focus moves to body, breaking focus containment
See original GitHub issue🐛 Bug Report
FocusScope exhibits confusing behavior when a focused element unmounts, potentially allowing focus to travel outside of a FocusScope even when contain is set to true.
🤔 Expected Behavior
I would expect that when a focused element is unmounted, focus travels to a different element within the FocusScope, when contain is true.
😯 Current Behavior
When a focus element within a FocusScope unmounts, focus travels to <body> rather than another element within the focus scope.
🔦 Context
I am implementing a modal that renders a form with radio buttons on mount. Prior to the radio buttons being returned from the fetch, I show a loading indicator. I attempted to use the loading indicator as the focus target for the modal, assuming that when the loading indicator unmounts then the first form option would be rendered. Instead, focus traveled to body which is outside of my FocusScope.
💻 Code Sample
Sandbox with issue reproduced: https://codesandbox.io/s/thirsty-mahavira-dof7z?file=/src/App.js
Code in case sandbox becomes unavailable:
import React from "react";
import { FocusScope } from "@react-aria/focus";
export default function App() {
const [focused, setFocused] = React.useState();
const [buttonIsVisible, setButtonIsVisible] = React.useState(true);
React.useEffect(() => {
window.addEventListener(
"DOMSubtreeModified",
() => {
setFocused(document.activeElement.tagName);
},
true
);
window.addEventListener(
"blur",
() => {
setFocused(document.activeElement.tagName);
},
true
);
window.addEventListener(
"focus",
() => {
setFocused(document.activeElement.tagName);
},
true
);
}, []);
return (
<div className="App">
<FocusScope contain>
<h1>Focused Element Tag: {focused}</h1>
<button>Focus me next please</button>
{buttonIsVisible && (
<button
onClick={() => {
setButtonIsVisible(false);
}}
>
Press me to delete me
</button>
)}
</FocusScope>
</div>
);
}
🌍 Your Environment
| Software | Version(s) |
|---|---|
| react-spectrum | “@react-aria/focus”: “^3.1.0” |
| Browser | Chrome: 84.0.4147.105 |
| Operating System | MacOS 10.15.5 |
🧢 Your Company/Team
ButcherBox/Engineering
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
The principal use case for which I’d like to see a solution is a dialog opened from a popover, like a menu, that closes when the dialog opens, where closing the FocusScope for the dialog expects to restore focus to an element that no longer exists. For this I think we need a stack of FocusScopes that can be updated when a scope is removed, so that closing the top scope always restores focus to an element that exists in the previous scope.
A secondary use case would be for elements in the same scope where the item that has focus can be removed, losing focus to the document body, like a Tag list of keywords for filtering, or items in a collection that can be removed by clicking a button in the item. FocusScope may or may not need to account for this, because focus management when an item is removed might best be handled by the TagList or Collection, setting focus to the previous or next item if one exists. I’m less inclined to arbitrarily set focus to the next or previous tabbable element in the DOM, which may be a different, unrelated element type.
a thought i had on this is that if focus moves forward, the user may not know what was next, so they may think they’ve been dumped somewhere random. would it make more sense for focus to go to the previous item? presumably where they came from? unless of course they were shift tabbing. I don’t know if it makes sense to build up a stack of where the user has been in terms of focus, that could get hard to manage. The application may need to decide/track this