Navigation Block: Toolbar overlaps with submenu links when opening sidebar or using smaller viewport

[letasync]

Description

Navigation toolbar overlaps on submenu links when we open sidebar settings or on smaller viewport. This makes editing or addting submneu links difficult.

Step-by-step reproduction instructions

1. Add navigation block
2. Add page link
3. Add submenu links
4. Open setting sidebar or test on smaller viewport

Screenshots, screen recording, code snippet

Uploading Error Sub menu.mp4…

Environment info

WordPress - 5.9.3 on local
Gutenberg - 13.0.0
Default Theme
No other plugin or theme installed.
Browser - Chrome

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

[letasync]

Error.Sub.menu.mp4

[ndiego]

I can confirm that the current UI makes it very difficult to edit Navigation blocks. I included a gif of my testing.

[talldan]

This isn't the first time this has been reported:

• Site editor toolbar positioning underneath blocks can make it difficult to edit some blocks #36335
• Navigation block: Unable to use sub-menu item & deletion deletes parent menu #36977

Both issues seem to have been closed when they shouldn't have been, which means the issue has been untracked for some time 😞 .

[letasync]

@ndiego Thanks for testing and confirming the issue.
Indeed it's difficult to edit navigation block.

I have been tracking the development of Navigation Block and related issues continuously and as per my understanding it might take longer time to get this #38275 completed. Till that time we need some kind of temporary quick-fix for Navigation Block. I hope @getdave may be the right person to suggest something on this.

@talldan yes this perticular issue has been there for long time.

[getdave]

I think this comment by @Addison-Stavlo has the best summary of options.

I took this for a spin and sought to try and identify the Nav Submenu and place the toolbar according to it's height. This is what I ended up with

Screen.Capture.on.2022-04-25.at.11-55-16.mp4

It's very rough and to achieve it would require either:

• identifying any positioned children and accounting for them in the positioning logic
• allowing a block to provide a specific positioned child to be accounted for in the positioning logic

I could look to refine this a little more if we feel it's heading in the right direction.

[annezazu]

Just ran into this with 6.0 RC3 and it made adding a sub menu to the nav block feel frankly unusable:

nav.block.covered.mov

@getdave is this still on your plate? If so, I think this needs to be considered for 6.0.x cc @ndiego

[getdave]

I've been waiting for @youknowriad to land the new Popover changes. But it's a very difficult problem. I have a prototype solution in #40625 but I'd love more 👀 on it.

[getdave]

Related #42010

[annezazu]

Noting that this came up twice with the seventeenth call for testing with the FSE Outreach Program:

Clicking Blog I expected to see a + sign below it just like I see the + sign square next to the last link in the menu. I clicked the Add Sub Menu icon in the toolbar. Noticed that the toolbar partly overlaps the field to where I would write the name of the submenu item. I am not able to click into the new text field for the submenu. I had to go into the sidebar and write the Link Title. That did not help as the Navigation toolbar is overlapping the submenu. — Not able to finish this task.

When having at least one sidebar open (list view or settings), the block toolbar of the menu item jumps below the menu item. When adding submenu items then by clicking on the block toolbar icon to add a submenu item, the block toolbar overlays the field for the submenu. It can be added, however the block toolbar is just “in the way”. Closing both sidebars puts the block toolbar at the top again and allows adding submenu items without problems.

[mrfoxtalbot]

There is a PR in place that should fix this #43530 cc @javierarce

[annezazu]

Despite a PR that was merged for 14.6, the nineteenth call for testing for the FSE Outreach Program found this bug once more:

Going back to Home template. This time I clicked into the Header template to focus on the Nav block. The Nav block toolbar is still covering the submenu.

And again:

In customizing the menu – I made changes to the colors of the submenus – but when I tried to view my changes, the block settings got in the way, so I could not see my changes at all: https://cloudup.com/cocT9dqQ8MF

There's a video using replay.io, a new tool that allows you to see the actually environment in which an issue can be replicated. Happy to give someone access as we test this tool out to review and see what's going on :)

[tnchuntic]

Yes that issue/bug still existing, its a bit a pain specially if you editing a horizontal navigation. My workaround it is to change orientation to vertical then edit the menu that I need to update then revert back to horizontal after. :) Painful but that how it is for now... I am positive that all of the issue will be fixed in the future and wordpress will be awesome again... Yaay.

[getdave]

Another option in the future will be using the offcanvas navigation if that experiment is accepted going forward for inclusion in Gutenberg Core.

[noisysocks]

A variation of the same bug is if you have the Navigation block positioned at the top of the screen.

1. Install and activate Emptytheme, or use the Create Block Theme plugin to create a new empty theme.
2. Go to Appearance → Editor and edit the default template.
3. Insert a Navigation block into the first position in the header template part.
4. Edit the Navigation block and add a submenu to one of the navigation items.
5. Try to edit the submenu.

Kapture.2024-06-04.at.11.43.41.mp4

[noisysocks]

Spent some time playing with this. Mostly it's a design problem, so paging @jasmussen who's thought about all of this before.

To recap, here's what things currently look like. The toolbar positions itself below the selected block (Navigation) as there isn't enough room above the Navigation block. This obscures the submenu and results in an experience that feels really broken.

1. One option is to always show a frame around the editor, the same as we currently do for template parts. This means there will always be enough space for the toolbar to appear above the selected block. This is essentially how Notion and Craft solve this problem—they have a lot of whitespace at the top of the editor. The downside is that we'd be ditching our current convention of the frame denoting that you're editing a template part.

   

2. Another option is to always position the toolbar above the block but stack it on top of the document header if need be. The downside of this is that the document header is obscured, but at least you can deselect the block.

   

3. And one last option is to keep positioning the toolbar below the selected block when needed, but to consider overflowing content (e.g. the submenu) to be a part of the selected block's bounds. This is what @getdave explored in [WIP] Account for positioned elements when positioning Block Toolbar #40625. A downside of this approach is that the submenu can be arbitrarily large, which could make the toolbar disappear off the bottom edge of the screen.

   

I don't really like (3) as submenus can grow arbitrarily large. If we can figure out a more cohesive design for (1), I'd prefer it. If not, I prefer (2).

[jasmussen]

Thanks for the ping, important one to solve. It's also important to solve holistically; this is presently an issue with navigation submenus. But there are endless block types plugins could create, that would cause similar issues.

One option is to always show a frame around the editor, the same as we currently do for template parts.

This is not uniformly a solution, as it would require the frame to be at least as tall as the block toolbar itself, plus the margin, in order to fit contexts where the block goes fully edge to edge. That would come to 48+8px at the moment, which if we add that all around the canvas, it ends up a lot.

Option 3 seems hard to build in a generic way that would be aware of what a custom block might be doing. But if it could be addressed in a completely generic way, it does seem to be the best practice for similar cases. Here's an example from Figjam, where the toolbar behaves in this way:

Could an idea be that instead of the toolbar being aware of only the top edge of the screen, that it could be aware of that, plus the footprint of the selected block? Problably tricky, since the dropdown menu is abs-positioned, which makes it hard to calculate the height of the block. But this might otherwise have been good to combine with the "absorb toolbar" feature, which captures child block toolbars in the parent toolbar, as shown here for the list block:

Option 2 could be a plan B.

Lastly, we still need to enable focus mode on virtually any block, at least container blocks (#45264). This would not solve the issue specifically since you should still be able to edit navigation in visual context of the rest of the page, but it might offer an additional affordance for editing complex blocks.