"More options" dropdown menu stuck after removing block

[svenvanhal]

Describe the bug
The "More options" menu (three dot button) in the Top Toolbar is stuck when a block is removed using the arrow keys.

Using Gutenberg 5.4.0-rc.1.

To Reproduce
Steps to reproduce the behavior:

1. Add new post
2. Select the first block ("Start writing or type / choose a block")
3. Press ALT + F10, Arrow Left, ENTER to open the "More options" dropdown.
4. Select "Remove Block" with the arrow keys
5. Observe that the dropdown menu stays open.

To confirm the issue, add any number of blocks and try these steps on a random block.

Expected behavior
The dropdown menu should close after the block is removed.

(Note: the menu also stays open when performing these steps with the mouse, but can be closed by clicking anywhere on the screen. This is only possible using the keyboard by selecting the post title, because it does not have a more options menu.)

Desktop (please complete the following information):

• OS: Windows 10 (build 1809)
• Browser Firefox Developer Edition
• Version 67.0b6

[youknowriad]

@aduth I wonder if this is related to the change made recently about the toggles behavior.

[aduth]

@aduth I wonder if this is related to the change made recently about the toggles behavior.

I assume you mean #14456 ? It doesn't appear that it should be related, as the pull request affected specific menu options in the editor "More Options" menu, whereas this one appears to be related to block options menu.

I've reproduced the issue. I assume it's likely related to how we forcibly re-insert a default block when all other blocks are removed. This re-insertion likely triggers focus to be moved to the block and out of the menu.

gutenberg/packages/block-editor/src/store/actions.js

Lines 404 to 406 in 9af3f42

	if ( count === 0 ) {
	yield insertDefaultBlock();
	}

gutenberg/packages/block-editor/src/components/block-list/block.js

Lines 82 to 86 in 9af3f42

	componentDidMount() {
	if ( this.props.isSelected ) {
	this.focusTabbable();
	}
	}

I assume that if this analysis is correct, the bug will have been present for a while. That said, the insertDefaultBlock behavior was recently refactored as part of #14189 (cc @jorgefilipecosta ).

I'd suggest action items:

• Find a way to avoid focus changes as part of the "ensure default block" behavior, or reimplement the behavior such that backspacing in the first empty block will simply behave as a noop (rather than having a new block be reinstated after the fact)
• Make sure that dropdown menus become closed when focus leaves

[aduth]

Part of the problem is also that selecting the menu items does not close the menu. I'm unsure whether it was done so intentionally, but my reading of the recommendations is that the menu should be closed.

I wonder also if it's something we can improve in the abstractions and relationships between Dropdown and MenuItem components. There's also DropdownMenu which... is neither used by the block settings menu, nor itself uses the MenuItem component. At least in how it is implemented, it may serve as a suitable replacement for the block settings menu's use of the more generic Dropdown component, with the auto-close behavior built in.

[aduth]

Closing in favor of #15313 , which is technically the duplicate as it was created later, but includes some additional useful context from the recent accessibility audit.