Editing newly created Nav Link text using sidebar causes focus to move to previous link item

[getdave]

Description

When creating a new Navigation link item you may wish to amend the label text using the block's sidebar controls. However, when you do so the focus is placed back on the previous Navigation item.

It's hard to explain so please watch the video to understand.

Step-by-step reproduction instructions

1. Add some links to a Navigation block
2. Ensure block's sidebar is open.
3. Add a new link to /.
4. Attempt to edit the label of the block using the Text field in the sidebar controls
5. See that as soon as it's focused the previous block is selected.

The culprit is almost certainly this line

gutenberg/packages/block-library/src/navigation-link/edit.js

Lines 601 to 604 in cddf656

	} else {
	// Fallback
	selectPreviousBlock( clientId, true );
	}

...which was added in 0cea924

Screenshots, screen recording, code snippet

Screen.Capture.on.2024-12-16.at.17-35-26.mp4

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[getdave]

@jeryj Do you have any more context on why we are selecting the previous block as a fallback? There's no context in the code except the comment "fallback".

0cea924

[getdave]

What we actually want to do here is not micro manage the focus if the close is in the sidebar. We could do this by adding a state to track if the focus is in the inspector controls but I"m wondering if thats a bit heavy handed.

[Mamaduka]

I think @alexstine was working on something similar. See #61374.

[getdave]

Thank you. I'm glad to see a more detailed solution is/was in the works.

However, that effort seems to have totally stalled and has a number of potential knock on effects.

I wonder whether shipping #68044 as a "hotfix" for Navigation and then looking again at #61374 would be a compromise folks would be happy with in order to this bug fixed for users of WordPress in the short term?

[jeryj]

tl;dr: There's a deeper issue here. The hotfixes we've added to cover the root issue are causing the problem, so let's fix the root issue.

The code causing this issue is a hotfix covering a deeper issue that @ajlende and I are looking at: The block list appender doesn't receive focus when the quick inserter closes.

We've figured out it's due to the useFocusReturn sending focus to the iframe and not the appender because, to the popover which is outside the modal, the iframe is what is focused.

I'm hopeful we can figure out a solution of either:

• Modify onFocusCapture to allow focus to get sent back to the appender
• Update useFocusReturn to set the previously focused item as whatever is focused within the iframe, not the iframe itself.

[getdave]

tl;dr: There's a deeper issue here. The hotfixes we've added to cover the root issue are causing the problem, so let's fix the root issue.

Absolutely. It seems there are several interconnecting streams here.

I'd much rather avoid "hotfixes" but by the same token I'd rather not see WP 6.8 land with this bug still in evidence.

Let's see how we're faring at Beta 1.

Thanks for all the efforts around this.

[jeryj]

Hopefully we can have a PR up this week that helps remove these hotfixes.

[jeryj]

It doesn't fix this issue, but I think we can build off it to fix this issue properly. Needs review: #68060