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

Block More Options menu: arrows navigation doesn't work any longer #7443

Closed
afercia opened this issue Jun 21, 2018 · 6 comments · Fixed by #7480
Closed

Block More Options menu: arrows navigation doesn't work any longer #7443

afercia opened this issue Jun 21, 2018 · 6 comments · Fixed by #7480
Labels
[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 Jun 21, 2018

Seems to me this is a recent regression, noticed for the first time at WCEU contributor day. To reproduce:

  • Tab to the More Options ellipsis menu in a block or click directly on it
  • the menu opens
  • focus is correctly set on the first menu item

screen shot 2018-06-21 at 17 53 28

  • at this point, try to use down and arrow keys to navigate the menu: nothing happens
  • pressing Tab works
  • press Tab to move to the second item
  • try again the down and arrow keys
  • arrows navigation works only on the last three items
  • expected: it should work since the beginning, starting from the first menu item
@afercia afercia added [Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release labels Jun 21, 2018
@afercia
Copy link
Contributor Author

afercia commented Jun 21, 2018

P.S. notice in the screenshot above, when arrows navigation works on the last three items, the first item still looks "focused".

@afercia
Copy link
Contributor Author

afercia commented Jun 22, 2018

Seems to me it's failing for the same reason already fixed in #6483 and #5442: the menu item must be direct children of the menu. Is there any way to enforce this?

@afercia
Copy link
Contributor Author

afercia commented Jun 22, 2018

OK so seems to me #7199 broke arrow navigation, as the new Slot/Fill implementation renders a <div> element around the first menu item. What's the best way forward here? /Cc @youknowriad @aduth

@aduth
Copy link
Member

aduth commented Jun 22, 2018

There's #7231 which avoids the wrapping div, though more plainly, it seems odd that the NavigableMenu component which manages the key press and focus transitions is failing by the mere presence of a div.

@aduth
Copy link
Member

aduth commented Jun 22, 2018

This behavior appears to be the intent of the deep prop on the NavigableMenu component:

A boolean to look for navigable children in the direct children or any descendant. True means that any descendant can be considered navigable, and false means only direct children are considered.

https://github.com/WordPress/gutenberg/blob/master/components/navigable-container/README.md

It's not clear to me, even in reading through its introduction in #3303, why this prop is necessary vs. always being the default behavior.

@afercia
Copy link
Contributor Author

afercia commented Jun 22, 2018

Yep I'm trying the deep prop, it works. But we should also ensure the div is completely ignored by assistive technologies adding a role=presentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature does not function as intended [Type] Regression Related to a regression in the latest release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants