-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(sidenav): unable to close by pressing escape in side mode #17967
Conversation
We currently listen for `keydown` events on the sidenav so that we know when to close it, however in `side` mode we don't trap focus inside the sidenav which means that unless the user goes into the sidenav manually, the escape listener won't work. These changes fix the issue by listening to keyboard events at the `document` level. Fixes angular#17965.
Is this actually the behavior we want? I'm not sure it makes sense to close the sidenav on escape if the focus isn't somewhere in the sidenav |
I suppose that it depends on how we treat the sidenav in |
I think it might depend on individual apps, I could see wanting to do it either way. With the other modes they're modal so its a little more clear. I think we should just leave it as is, and let users add an extra listener if they want it to close on escape in a different subtree |
Up to you. I submitted the fix, because the behavior felt inconsistent. |
Ok, I would prefer to leave it as is |
Is it somehow possible to capture focus, when opening the sidenav in "side" mode? I agree that it should only close on escape, if focus is on the sidenav. But is that not the case with the |
Good point that |
I'm not sure about turning on focus trapping because they specified |
Makes sense. I can do a separate PR tomorrow which adds that functionality. |
…explicitly This PR is the result of the discussions in angular#17967. Currently we don't move focus into the sidenav if it's in `side` mode, because we don't know the context that the component is used in, however in some cases it makes sense to move focus anyway. These changes make it so that if the consumer explicitly opted into `autoFocus`, we always move focus into the sidenav, no matter what mode it's in.
…explicitly This PR is the result of the discussions in angular#17967. Currently we don't move focus into the sidenav if it's in `side` mode, because we don't know the context that the component is used in, however in some cases it makes sense to move focus anyway. These changes make it so that if the consumer explicitly opted into `autoFocus`, we always move focus into the sidenav, no matter what mode it's in.
This PR is the result of the discussions in #17967. Currently we don't move focus into the sidenav if it's in `side` mode, because we don't know the context that the component is used in, however in some cases it makes sense to move focus anyway. These changes make it so that if the consumer explicitly opted into `autoFocus`, we always move focus into the sidenav, no matter what mode it's in.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
We currently listen for
keydown
events on the sidenav so that we know when to close it, however inside
mode we don't trap focus inside the sidenav which means that unless the user goes into the sidenav manually, the escape listener won't work. These changes fix the issue by listening to keyboard events at thedocument
level.Fixes #17965.