-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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(menu): not handling keyboard events when opened by mouse #4843
Conversation
src/lib/menu/menu-trigger.ts
Outdated
@@ -104,6 +107,14 @@ export class MdMenuTrigger implements AfterViewInit, OnDestroy { | |||
this._createOverlay(); | |||
this._overlayRef.attach(this._portal); | |||
this._subscribeToBackdrop(); | |||
|
|||
this._globalKeydownHandler = this._renderer.listen('document', 'keydown', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will this global listener play with, say, a menu inside of a dialog?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it'll close both the menu and the dialog. What about focusing the menu panel, instead of the first option, when the menu is opened by mouse?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The options are focused for a11y
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but it seems pretty deliberate that we're not shifting focus when the user opened it by mouse. If we want to keep that behavior, we could opt to move focus to the panel, if the menu was opened by mouse, or focus the first option if it was opened by keyboard. Otherwise we can also focus the first option for all cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kara do you remember why we don't move focus to the options when opening via mouse? If it was just to prevent the focus style from showing, we could probably just do that through css.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it was just for the visual treatment. I don't think there's any reason not to focus the options in itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How should I proceed in this case? Given that we also have #4991, should I just enable the keyboard navigation no matter how you opened the menu?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make it always focus the options no matter how you open the panel, but only show the initial focus style (before subsequent key presses) when it's triggered by keyboard
@crisbeto Can you rebase this? |
Done @kara. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed something odd while testing this. Here's how to repro:
- Tab to the menu trigger and hit enter to open.
- Navigate down to the second option with the arrow keys.
- Hit enter.
- Now open the trigger with your mouse.
- Hit the down arrow.
The focus will be on the next enabled option (the 4th) rather than resetting focus to the first option.
src/lib/menu/menu-trigger.ts
Outdated
// If the menu was opened by mouse, we focus the root node, which allows for the keyboard | ||
// interactions to work. Otherwise, if the menu was opened by keyboard, we focus the first item. | ||
if (this._openedByMouse) { | ||
let rootNode = this._overlayRef.overlayElement.firstElementChild as HTMLElement; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The _overlayRef type is sometimes null, so the strictNullCheck in the build is complaining. Add a !
?
4e4f6c3
to
7b56290
Compare
@kara can you take another look? |
@kara Implemented the approach as discussed. |
@crisbeto Sorry for the delayed review on this. Do you mind rebasing again? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Note: needs internal updates. Breaking. |
ed99a0a
to
25fbc95
Compare
Fixes the menu keyboard interactions not working when it is opened by a click. Fixes angular#4991.
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. |
Fixes the menu keyboard interactions not working when it is opened by a click.
Fixes #4991.