Block options menu: initial focus skips the first menu item

[afercia]

Description

When the 'Options' menu in the block contextual toolbar opens, initial focus is expected to be set to the first menu item. Instead, it's set on the second menu item.

Step-by-step reproduction instructions

• Edit a post.
• Select a paragraph to make the block contextual toolbar appear.
• Click the last button within the toolbar to open the 'Options' menu.
• Observe the initial focus within the menu is set to the 'Copy block' menu item, which is the second item.
• Instead, it should be set to the first item 'Hide more settings'.

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

[afercia]

When opening the menu, useFocusOnMount is responsible for setting the initial focus. It finds all the 'tabbable' elements and sets focus on the first one:

gutenberg/packages/compose/src/hooks/use-focus-on-mount/index.js

Lines 45 to 53 in 691f2ef

	if ( focusOnMountRef.current === 'firstElement' ) {
	const firstTabbable = focus.tabbable.find( node )[ 0 ];
	if ( firstTabbable ) {
	target = /** @type {HTMLElement} */ ( firstTabbable );
	}
	}
	target.focus( {

In the screenshot above:

• I'm dumping all 'tabbable' elements focus.tabbable.find( node ) to the console.
• useFocusOnMount finds 9 tabbable elements.
• However, there are actually 11 tabbable menu items within the menu.
• The 2 missing items are:
  • 'Hide more settings'
  • 'Add to Reusable blocks'

My guess: it's about timings. It appears useFocusOnMount runs before those two menu items are actually rendered.

Hide more settings
It renders via __unstableBlockSettingsMenuFirstItem which is a Slot/Fill implementation, which appears to render the menu item after useFocusOnMount ran.

Add to Reusable blocks
I'm not sure I can follow this implementation but it appears it renders later anyways.

Note:
I'm guessing the sam problem that occurs with __unstableBlockSettingsMenuFirstItem may happen also with __unstableBlockToolbarLastItem.

Overall, this seems a more general issue that's not limited to the block settings menu.

useFocusOnMount expects the DOM to be fully rendered. It appears that using Slot/Fill and similar implementations in places where useFocusOnMount isn't ideal, as it makes useFocusOnMount fail.

[afercia]

In my testing, using the setTimeout 0 workaround in useFocusOnMount would fix the issue.

Turns out useFocusOnMount used to have a SetTimeout that was removed in #27699. I do understand the reasons why it was removed, but it appears that change didn't take into account components that are mounted at a later time within the parent component where useFocusOnMount runs.

I don't know enough about some implementation details (e.g. whether the Slot/Fill implementation for the first item is really needed) so I'd defer to someone with greater knowledge than me. Cc @ellatrix @youknowriad