Skip to content
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

(React) Menu steals focus from modal on Menu.Item click #259

Closed
reczy opened this issue Feb 25, 2021 · 7 comments
Closed

(React) Menu steals focus from modal on Menu.Item click #259

reczy opened this issue Feb 25, 2021 · 7 comments
Assignees

Comments

@reczy
Copy link

reczy commented Feb 25, 2021

Hi there,

First of all, thanks so much for tailwind and tailwindui!

The issue I'm facing relates to the latest release of @headlessui/react.

I have a Menu component with a Menu Item that opens a modal (react-modal). The modal contains a form with an autofocus input that should grab and maintain focus on modal open. The problem is that the Menu Button steals focus away from the modal (so - focus is on the Menu Button behind the modal overlay) after Menu.Item click.

As a temporary-but-not-great workaround, I found that using setTimeout to slightly delay opening the modal after Menu.Item click usually results in the modal form getting and keeping focus.

I think this might be related to #47? Is there a proper way to prevent the Menu Button focus?

Thanks!

@RobinMalfait
Copy link
Collaborator

Hey! Thank you for your bug report!
Much appreciated! 🙏

The Menu should not "steal" focus, however if you click on a Menu.Item it should restore focus to the Menu.Button for accessibility reasons (otherwise screenreader users could get lost when suddenly the body is focused).

Do you mean that once you clicked on the Menu.Item that it should restore the focus to the input field? If that's the case then you can do something like this:

<Menu.Item as="button" onClick={() => {
  // Do what you need to do here
  inputRef.focus()
}}>
...
</Menu.Item>

If this doesn't work, or the behaviour you want is different, please provide a reproduction repo/codesandbox.

@reczy
Copy link
Author

reczy commented Mar 5, 2021

Hey @RobinMalfait - thank you for taking the time to respond. I appreciate that the current behavior is probably desired in most cases and so hesitated to actually call this a bug in my opening comment.

I was able to reproduce what I'm experiencing in codesandbox here. Apologies in advance for the quick and dirty code :)

I started out going the ref route like you suggest, but the code was starting to look a bit convoluted - I reuse various "base" modals, each of which can correspond to different types of records, contain different forms, inputs, etc, and the forms themselves are abstracted a bit and can be a few layers deep.

Ideally, there would be a boolean toggle to skip the restoration of focus to Menu.Button.

Let me know if any additional information would be helpful. Thanks again for your consideration!

@reczy
Copy link
Author

reczy commented Apr 22, 2021

Hi @RobinMalfait - I am no longer experiencing this issue after refactoring my code and switching from formik + react-modal to react-hook-form + the headless ui modal implementation.

Thanks for your consideration.

@reczy reczy closed this as completed Apr 22, 2021
@mikeuduc
Copy link

Hi @RobinMalfait - I'm having the same problem where the focus is "stolen" by the Menu.Button upon closing of the Menu.Items.

I'd like to provide an "actions" menu option to edit a user generated field by focusing on it (in my case I'm using textarea, but this could also be a text input). The use case seems common enough, for example Monday.com has a menu item to "Rename board" which will focus the board name input.

Using similar example code that you provided, I'm trying to focus a text area onClick of a Menu.Item. https://codesandbox.io/s/stoic-bose-xvn1nz?file=/src/App.js

You can see that the textarea flashes because it it focused, then immediately focus is "stolen" by the Menu.Button. You can also see the logged output for onFocus and onBlur events for the textarea for confirmation.

Hope this helps provide some context. I agree with @reczy that it would be great to have an option to skip the focus to Menu.Button.

@dylancom
Copy link

Same problem here and using refs didn't fix it.
Currently as a quick fix I use a timeout of 50ms to open a modal.
In that case react-modal's focus management works fine.
getAlby/lightning-browser-extension#709

@kstoddard
Copy link

kstoddard commented Jun 3, 2022

I also hit the issue triggering the Dialog from a Menu but got around that by passing static to the Menu and programmatically using the open render prop to show the menu (that seems to release focus long enough to trigger the click on the Dialog). That said, I am seeing other issues that seem related to managing focus...

As mentioned, I am opening a Dialog from a Menu, in the Dialog there is a form with a textarea to add a note. Once the Dialog is open and focus is placed within the textarea, you can type BUT you cannot add "spaces" or use the "enter" key as focus seems to be applied to the Menu still.

I am still investigating in light of my use case and trying to make sure the issue is not "operator error", so far doesn't seem to be. If anyone has hit this and has help, please share. Thanks

(using @headlessui/react: ^1.6.4)

Edit

I should add (since it might not clear from my description) that the Dialog and button to trigger it both live inside of the Menu item. This is because we are iterating over a large collection of data and generating cards with a Menu that have "actions" for the card. Therefore, because each Dialog needs to have content specific to that iteration, we are just nesting it along with the Menu item. With that said, I may just need to rework how we are associating each Menu and its Dialog. That child/parent relationship may be causing this problem.

@manodrum
Copy link

Posting here for future reference, this was fixed in #1782

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants