Navigation Block: Hide the toolbar when NavigationLink popup is opened

[WunderBart]

Description

Closes: #18315

Hide the BlockToolbar when the NavigationLink popup is opened. This happens in 2 instances:

1. After clicking the ⊕ button,
2. After clicking the 🔗 button (or pressing CMD/CTRL-K).

Note that this doesn't force the BlockToolbar to remain hidden until the popup is closed - it will become visible on e.g. any mouse movement regardless of the popup visibility.

How has this been tested?

In the Navigation block, click on the ⊕ button to add a new item. An empty item should be appended with link popup opened and its input focused and the BlockToolbar should be hidden.

Screenshots

Types of changes

Non-breaking change.

Checklist:

• My code follows the WordPress code style.
• My code has proper inline documentation.

[WunderBart]

Note that this doesn't force the BlockToolbar to remain hidden until the popup is closed - it will become visible on e.g. any mouse movement regardless of the popup visibility.

Because of this, proposed enhancement is almost unnoticeable because after clicking the ⊕ button you'd most certainly move the cursor at least 1px, which is enough to unhide the toolbar (the demo gif is an idealized version - I did the effort to keep the post-click cursor still 😉). I'm not sure how this could be approached otherwise though - maybe actually keep the toolbar hidden until the link popup is closed? I feel like this could cause some unexpected issues, though. Appreciate any feedback on this @karmatosed @shaunandrews 🙏

[apeatling]

I feel like this could cause some unexpected issues, though

Anything come to mind here? I was going to suggest the same thing having tested this. Hide it until you select something in the popup, or click outside to close it.

[WunderBart]

Anything come to mind here?

Nothing concrete so far - just the fact that we'll need to prevent the default toolbar behavior, I guess. First, I'll need to find a way to keep it hidden and then do some testing. Will update soon!

[getdave]

I don’t think startTyping is the best way forward as it's implementation may change in future and the toolbar may continue to display even when "typing".

Perhaps take a look at packages/block-editor/src/components/block-list/block.js.

You’ll see the shouldShowContextualToolbar (partially) determines toolbar display on/off. You’d need to dispatch an action that causes a change in that value.

Probably requires a new action to be dispatched to the block editor store.

[getdave]

Related: #19561

[jasmussen]

These days I'm working on implementing parts of the new UI efforts from #18667 in #19344.

One of the observations that has emerged from removing the gray outset "block is being edited" border is that what actually has focus is becoming much clearer. In this image, the Spacer block has focus, and if you press Delete the block is removed. If you press Shift tab, the blue outline around the spacer moves to the block toolbar instead. This GIF of the placeholder shows how focus journeys from the block itself to buttons inside.

While the precise interaction is still being explored, it does suggest that the general idea, showing UI controls for the element being edited, rather than necessarily the element and the block, might have merit. And it seems the idea being explored here is in this vein also.

I do wonder if there is a way we can approach this which is generic to all blocks, and not just one-off code for the navigation block. The equation is this:

• For every enhancement we make to the block itself, we can potentially benefit every block that ever was or will be.
• For every enhancement we make to just one block, we risk creating technical debt that is either forgotten or unmaintained in the future.

There's a time and place for block-specific enhancements, but it's good to ponder whether this is it.

[mtias]

I agree with @jasmussen. There are multiple interactions that could warrant the same experience as isTyping and we should try to reason coherently about them so that we don't end up with blocks behaving differently or idiosyncratically.

[WunderBart]

I'm closing this one as we don't want to allow Toolbar visibility changes via API and can't currently detect reliably whether the block content is edited externally (e.g. via LinkControl popup), which would allow us to make Toolbar smarter and hide itself when needed. Let's keep an eye on #19344 and see if we can get back to this issue when it's in.