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

Command Center: Keyboard Focus lost when toggling Editor Preferences or Code Editor #52301

Closed
jordesign opened this issue Jul 5, 2023 · 10 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Commands /packages/commands [Package] Compose /packages/compose [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release

Comments

@jordesign
Copy link
Contributor

Description

When toggling panels like the Editor Preferences or Code Editor - the editor no longer has focus once those are closed, so the keyboard shortcut for the Command Center doesn't work.

Step-by-step reproduction instructions

  1. Open the Site Editor and edit a template or page
  2. Use the command-k shortcut to confirm the Command Center loads - use it to open the Editor Preferences.
  3. Close the Editor Preferences
  4. Use the command-k shortcute to try and open the Command Center again

Screenshots, screen recording, code snippet

No response

Environment info

  • WP 6.3 beta 2
  • Gutenberg 16.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@jordesign jordesign added [Type] Bug An existing feature does not function as intended [a11y] Keyboard & Focus [Package] Commands /packages/commands labels Jul 5, 2023
@stokesman
Copy link
Contributor

In regards to the Editor Preferences, I think it depends on how you close the Modal. Using the close button or pressing Esc should maintain focus as expected. Clicking outside the modal drops it #51722.

For the Code Editor, I confirm it doesn't matter how you engage/disengage (keyboard shortcut or Options menu) focus is lost.

@jordesign
Copy link
Contributor Author

I find this also happens when opening/closing the Command Center/Palette with the mouse.

after triggering the command palette by clicking in the title bar at the top, and then clicking outside the palette to remove it - the main window no longer had focus - so the keyboard command would not work.

@annezazu
Copy link
Contributor

@afercia @alexstine @joedolson in case any of you can test and provide feedback here <3

@joedolson
Copy link
Contributor

Yes, I can confirm that this happens. The focus is handled on esc, but not on mouse click. It seems to me that focus placement should be connected to the action ("close the modal") rather than to the event ("press esc"), so that it is consistent regardless of the mechanism used for closing.

Also, I don't understand why the command center doesn't have a close button.

@afercia
Copy link
Contributor

afercia commented Jul 14, 2023

Also, I don't understand why the command center doesn't have a close button.

I'd second this. All modal dialogs should always have a CLose button. The Modal component dos provide it by default but it has an option to hide the dialog header, including the Close button. There are other cases of modal dialogs where the dialog header is hidden, I guess only for visual design purposes.

Regarding this specific issue:

Switching between Visual editor and Code editor

Focus should stay in the most appropriate place but there are two different cases to consider:

  • Switching via the Options menu: I think focus should stay on the button that has been activated.
  • Instead, when switching via keyboard shortcut Shift+Option+Command+M focus should stay where it was, or be set to the most appropriate place e.g.:
    • One of the blocks is selected? Shift+Option+Command+M > focus is set on the Code textarea > Shift+Option+Command+M > focus is set back on the block that was selected
    • Any other UI control is selected? Shift+Option+Command+M > focus stays on the focused control, whatever it is.

Implementing some proper focus management would solve the Cmd+K shortcut issue.

Modal dialogs

The Modal component default behavior is:

  • When the modal dialog, focus is restored to the control that opened the modal dialog.
  • Not surprisingly this pattern can't work when a modal dialog is opened via the Command center, simply because the focused control that opened the modal dialog (the item in the Command center) isn't in the DOM any longer. As such, focus is lost and the Cmd+K shortcut doesn't work.

Worth noting that this impacts any keyboard shortcut, not only Cmd+K. When focus is lost, no element in the main window has focus. Other shortcuts e.g. Control+Option+H won't work.

Overall:

  • Keyboard shortcuts don't work any longer when there's a full focus loss.
  • The way the Command center has been designed breaks the Modal component focus management (and possibly other components focus management). I'd consider this a regression. I'm going to mark this issue as such.

@afercia afercia added [Type] Regression Related to a regression in the latest release [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Compose /packages/compose and removed Needs Accessibility Feedback Need input from accessibility labels Jul 14, 2023
@afercia
Copy link
Contributor

afercia commented Jul 14, 2023

For reference: the modal dialog 'focus on close' management is handled by useFocusReturn from the compose package.

@annezazu annezazu moved this from ❓ Triage to 📥 Todo in WordPress 6.3.x Editor Tasks Jul 14, 2023
@annezazu
Copy link
Contributor

Adding to to do in 6.3. Thank you all for the feedback and testing!

@stokesman
Copy link
Contributor

Andrea’s breakdown of this is great 👏 . I'll make a PR later today for the return of focus from modals. The Code Editor part should probably be a separate effort.

@afercia
Copy link
Contributor

afercia commented Jul 18, 2023

Thank you @stokesman
I will create a separate issue for the Code / Visual editor.

@tellthemachines
Copy link
Contributor

Now that #52710 has been merged, and given that the code editor issue is tracked in #42145 are we good to close this one or is there still anything left to do here?

@github-project-automation github-project-automation bot moved this from 🏗️ In Progress to ✅ Done in WordPress 6.3.x Editor Tasks Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Package] Commands /packages/commands [Package] Compose /packages/compose [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
No open projects
Development

No branches or pull requests

7 participants