Improve FocusTrap behaviour
#1432
Merged
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
RobinMalfait
force-pushed
the
focus-trap-improvements
branch
from
e240204 to
0516e4c
Compare
RobinMalfait
force-pushed
the
focus-trap-improvements
branch
from
0516e4c to
b8b1b2d
Compare
This new component will also make sure that it is visually hidden to
sighted users. However, it contains a few more features that are going
to be useful in other places as well. These features include:
1. Make visually hidden to sighted users (default)
2. Hide from assistive technology via `features={Features.Hidden}`
(will add `display: none;`)
3. Hide from assistive technology but make the element focusable via
`features={Features.Focusable}` (will add `aria-hidden="true"`)
This will behave the same (roughly) as the new to be released `useEvent`
hook in React 18.X
This hook allows you to have a stable function that can "see" the latest
data it is using. We already had this concept using:
```js
let handleX = useLatestValue(() => {
// ...
})
```
But this returned a stable ref so you had to call `handleX.current()`.
This new hook is a bit nicer to work with but doesn't change much in the
end.
This keeps track of the direction people are tabbing in. This returns a ref so no re-renders happen because of this hook.
This is similar to the `useEffect` hook, but only executes if values are _actually_ changing... 😒
Using a component directly allows us to simplify the focus trap logic itself. Instead of intercepting the <kbd>Tab</kbd> keydown event and figuring out the correct element to focus, we will now add 2 "guard" buttons (hence why we require a component now). These buttons will receive focus and if they do, redirect the focus to the first/last element inside the focus trap. The sweet part is that all the tabs in between those buttons will now be handled natively by the browser. No need to find the first non disabled, non hidden with correct tabIndex element!
Also added a hidden button so that we know the correct "main" tree of the application. Before this we were assuming the previous active element which will still be correct in most cases but we don't have access to that anymore since the logic is encapsulated inside the FocusTrap component.
We make sure that the Portal is cleaning up its `element` properly. We also make sure to call the `target.appendChild(element)` conditionally because I ran into a super annoying bug where a focused element got blurred because I believe that this re-mounts the element instead of 'moving' it or just ignoring it, if it already is in the correct spot.
Not really necessary, just cleaner.
RobinMalfait
force-pushed
the
focus-trap-improvements
branch
from
b8b1b2d to
33583ff
Compare
This was referenced May 11, 2022
|
@RobinMalfait I think this may introduce an issue when the It seems the hidden buttons get rendered near the bottom of the page, and are focusable, so it can end up scrolling the page down to put them in view. If you try this sandbox, click open button, hit tab, there's no bug. If you bump the version to Potential fix, requires a bit of global CSS: #headlessui-portal-root {
position: fixed;
height: 100%;
width: 100%;
} |
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.
This PR provides a bunch of improvements to the
FocusTrapinstead of trying to be "smart" about things.Instead of intercepting the
Tabkeydown event and moving the focus to the correct next/previous element, we will now render 2 hidden buttons at the beginning and the end of the Dialog. This means that all the Tab logic is handled by the browser and we don't do anything special in this case.The only case we have to handle is to make sure that when one of those hidden buttons receive the focus, that we get redirected to the correct element in the FocusTrap.
This also includes some cleanup!
Fixes: #1406
Fixes: #1391
Fixes: #1291