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

Regression: Dropdown menu not operable via keyboard with Safari #22047

Closed
afercia opened this issue May 2, 2020 · 9 comments
Closed

Regression: Dropdown menu not operable via keyboard with Safari #22047

afercia opened this issue May 2, 2020 · 9 comments
Labels
Browser Issues Issues or PRs that are related to browser specific problems [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release

Comments

@afercia
Copy link
Contributor

afercia commented May 2, 2020

Describe the bug
When using Safari, selecting the options from a dropdown menu with the keyboard arrow keys is impossible: instead, the arrow keys trigger navigation through blocks. I'm assuming this happens only for dropdown menus rendered within the blocks area.

It seems to happen only in Safari. Works in Chrome.

I don't seem to recall this happening in Safari thus I'm assuming the dropdown menu behavior regressed at some point. Marking this issue as a regression.

To reproduce
I can consistently reproduce the bug with Safari 13.1 on:

  • Gutenberg on WordPress 5.4.1
  • Gutenberg on WordPress trunk
  • Latest Gutenberg plugin 8.0.0 – 021f69b

Steps to reproduce the behavior:

  1. Click on a paragraph
  2. Click the text alignment button: a dropdown menu opens
  3. Use the keyboard Up and Down arrow keys to navigate through the dropdown menu options
  4. Observe the menu closes and arrow navigation through blocks kicks in, making impossible to select any option from the menu

Animated GIF:

safari

Note: When explicitly exiting / entering edit mode by pressing Escape and then Enter, the menu behavior may be slightly different but after some up/down arrowing the menu will unexpectedly close anyways.

In Chrome (version 81 at the time of writing), everything works as expected. Animated GIF:

chrome

Expected behavior
The menu should stay open: arrowing should loop through the options withih the menu.

@afercia afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Regression Related to a regression in the latest release labels May 2, 2020
@gziolo
Copy link
Member

gziolo commented May 2, 2020

What about other menus outside of the block toolbar? Earlier this week I noticed some issues when using arrow keys a few times but in general it was working.

@afercia
Copy link
Contributor Author

afercia commented May 3, 2020

Looks like other menus suffer from the same problem. For example: the Tools menu in the top toolbar:

menu-arrow-keys

  • make sure the cursor is within a block
  • click the Tools menu in the toolbar
  • use arrow keys to navigate the Tools menu options
  • the menu closes and arrow navigation between blocks is triggered
  • and here's the trick:
  • make sure the cursor is not within a block, e.g.: click on an empty area outside of the blocks
  • repeat the steps above
  • arrow navigation in the Tools menu works as expected

Again: this happens only in Safari. Haven't tested IE.

@diegohaz
Copy link
Member

diegohaz commented May 7, 2020

I can consistently reproduce this bug on Safari by following these steps:

  1. Create a paragraph block.
  2. Write something and click on the text (ensure that the cursor is not at the end of the content).
  3. Click on any dropdown menu button on the toolbar (note that on Safari the cursor remains on the editable content).
  4. Press the arrow down key.

The dropdown menu closes and the cursor in the editable content moves to the end of the text.

On Safari, if the cursor is on a <div contenteditable="true"> and you click on a button, the closest focusable parent element receives focus (ultimately, the body element), but the cursor remains on the editable content element.

Pressing any key that changes the state of the editable content will move focus back to the editable content element. Since it generates a focus event outside the dropdown menu element, the dropdown gets closed.

https://output.jsbin.com/jiwacupufe/1

@ellatrix
Copy link
Member

ellatrix commented May 8, 2020

Any idea which commit caused the regression? Or has it always been like this?

@ellatrix
Copy link
Member

ellatrix commented May 8, 2020

Strange, the keyDown event on the content editable element is not fired.

@ellatrix
Copy link
Member

ellatrix commented May 8, 2020

I'm not sure if we can fix this tbh. Safari doesn't fire any keydown event. It sounds like a new Safari bug that's best reported to them. The selection should be able to stay in rich text, which is needed for example for the "more rich text tools" popover. Selection is not the same as focus, so keyboard events shouldn't act on selection without focus.

@diegohaz
Copy link
Member

diegohaz commented May 8, 2020

I guess we should be able to work around that by ensuring toolbar buttons receive focus when the user interacts with them. But this is super tricky, and I still couldn't find a way to do that properly without creating other issues (like disabling drag events).

@talldan talldan added the Browser Issues Issues or PRs that are related to browser specific problems label Jul 23, 2020
@stokesman
Copy link
Contributor

I was just testing this in Safari 12 and 14 and could not reproduce it in either. I tested trunk with Safari 12 and https://wordpress.org/gutenberg with Safari 14.

@mtias
Copy link
Member

mtias commented May 22, 2022

This seems to be working fine for me as well.

@mtias mtias closed this as completed May 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Browser Issues Issues or PRs that are related to browser specific problems [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

No branches or pull requests

7 participants