Can't re-assign focus to another Focus Trap #27
Assignees
Labels
Comments
JoaoTMDias
pushed a commit
that referenced
this issue
Jul 14, 2024
In order to fix the bug reported on issue 2, this commit does a re-implementation of the FocusManager, by replacing the current functionality, with the functionality provided by the "focus-trap" package. In order to keep the same API as before, it makes them still available as before, but changes the default values for autoFocus, restoreFocus and contain props. It also exposes the "focus-trap" API on the "options". BREAKING CHANGE: autoFocus, restoreFocus and contain are now set to true by default Closes #27
JoaoTMDias
pushed a commit
that referenced
this issue
Jul 14, 2024
In order to fix the bug reported on issue 2, this commit does a re-implementation of the FocusManager, by replacing the current functionality, with the functionality provided by the "focus-trap" package. In order to keep the same API as before, it makes them still available as before, but changes the default values for autoFocus, restoreFocus and contain props. It also exposes the "focus-trap" API on the "options". BREAKING CHANGE: autoFocus, restoreFocus and contain are now set to true by default Closes #27
JoaoTMDias
pushed a commit
that referenced
this issue
Jul 15, 2024
In order to fix the bug reported on issue 2, this commit does a re-implementation of the FocusManager, by replacing the current functionality, with the functionality provided by the "focus-trap" package. In order to keep the same API as before, it makes them still available as before, but changes the default values for autoFocus, restoreFocus and contain props. It also exposes the "focus-trap" API on the "options". BREAKING CHANGE: autoFocus, restoreFocus and contain are now set to true by default Closes #27
JoaoTMDias
pushed a commit
that referenced
this issue
Jul 15, 2024
In order to fix the bug reported on issue 2, this commit does a re-implementation of the FocusManager, by replacing the current functionality, with the functionality provided by the "focus-trap" package. In order to keep the same API as before, it makes them still available as before, but changes the default values for autoFocus, restoreFocus and contain props. It also exposes the "focus-trap" API on the "options". BREAKING CHANGE: autoFocus, restoreFocus and contain are now set to true by default Closes #27
github-actions bot
pushed a commit
that referenced
this issue
Jul 15, 2024
# [3.0.0](v2.0.1...v3.0.0) (2024-07-15) ### Bug Fixes * **FocusManager:** Replaces implementation with focus-trap-react ([#28](#28)) ([19bc86c](19bc86c)), closes [#27](#27) ### BREAKING CHANGES * **FocusManager:** autoFocus, restoreFocus and contain are now set to true by default * **FocusManager:** the `useFocusManager` was reimplemented. Since we no longer use a React context state management solution to travel between elements, the hook was re-implemented as an optional way to facilitate the creation of a `FocusTrap` instance, but without using the provided element by the package.
|
🎉 This issue has been resolved in version 3.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When using the
FocusManagercomponent inside, for instance, a Drawer, a Dialog or any other type of UI that needs focus trapping features, the trap works fine.However, when the user presses enter on, for instance, a button or something that opens another element that also requires focus to be drawn onto it (like a Popover, or another other UI that requires focus trapping as well), then the first
FocusManagerjust won't let go of the focus.Expected behaviour
Focus should be redirected as needed, when the user needs.
Desktop (please complete the following information):
Smartphone (please complete the following information):
The text was updated successfully, but these errors were encountered: