Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation Block: Adding layers of sub menu items causes editing field to expand #30113

Closed
annezazu opened this issue Mar 22, 2021 · 7 comments · Fixed by #30169
Closed

Navigation Block: Adding layers of sub menu items causes editing field to expand #30113

annezazu opened this issue Mar 22, 2021 · 7 comments · Fixed by #30169
Assignees
Labels
[Block] Navigation Affects the Navigation Block [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@annezazu
Copy link
Contributor

Description

Adding submenus can leave you with many submenus being created very quickly due to the “capturing” of the nested block’s toolbar so that it’s always pinned to the topmost Nav block – https://d.pr/i/fk9pVL/4E9DHVpjCm

Tied to this, after adding a bunch of submenus, if you try to view them all it ends up extending the actual editing field. This is obviously an edge case!

Feel free to update the title to something a bit more descriptive as I struggled to name this appropriately! This was found as part of the third call for testing for the FSE Outreach Program.

Step-by-step reproduction instructions

  1. Add a Navigaton Block
  2. Add a Link block
  3. Click “Add submenu” several times in rapid succession
  4. Try to view the submenu items that were created.
  5. See editor field expand :D Achievement unlocked!

Expected behaviour

Expect the add link to perhaps cascade down or somehow adapt to the overflow.

Actual behaviour

The add new link prompts expand the size of the editing field.

Screenshots or screen recording (optional)

fun.bug.mov

WordPress information

  • WordPress version: 5.7
  • Gutenberg version: 10.2
  • Are all plugins except Gutenberg deactivated? Yes
  • Are you using a default theme (e.g. Twenty Twenty-One)? TT1 Blocks

Device information

  • Device: Desktop
  • Operating system: MacOS
  • Browser: Chrome
@annezazu annezazu added [Type] Bug An existing feature does not function as intended [Block] Navigation Affects the Navigation Block labels Mar 22, 2021
@jasmussen
Copy link
Contributor

This is a wild one! #21691 will mitigate this one a little bit, as submenus will be limited to a depth of 5.

The video goes by a bit fast, but what happens, step by step, is actually this:

  • When you click the "Submenu" button, a "Link" block is inserted as a submenu.
  • This link block is focused and selected. If you click slow enough, it opens a submenu because it's a placeholder.
  • Because the newly inserted block is focused, clicking to add a submenu again correctly inserts a sub-sub menu. Which means as you click and click and click, well, it creates deeper and deeper levels of nesting, as that's the purpose of the button.

It seems like there's also an overlap into an issue that @gwwar has been looking into: what is the default block to insert? Right now it's making an educated guess at a "Link", but it shouldn't, because you might as well want to insert a "Page Link".

That said, the solution explored to that will still insert a placeholder block — just an even less defined generic block placeholder that doesn't yet know it's a menu item. I suppose that won't solve the incessant-clicking issue though, as it will still insert a block, focus it, and allow you to insert a deeper nesting level.

In the end that means there aren't that many good solutions for us to this one, as the button does what it's supposed to do. Short of throttling the button so you can't click it that fast, it seems like #21691 will need to be our solution.

@annezazu
Copy link
Contributor Author

Ah ha! Thank you for connecting the dots here. I wonder if this issue should remain open in light of the one you linked to? In my mind, the original issue covers the problem described here.

@jasmussen
Copy link
Contributor

I realized in testing this ticket that there's an adjacent issue, which I thought had been fixed by #29869 but it appears it hasn't. Observe this GIF:

menus

Notice how for most of the GIF the submenu being created stays open, but towards the end it disappears. The fact that it disappears is disruptive and a bug.

Right now the submenus are shown if the navigation block, or any child, is selected (is-selected or has-child-selected). However for some reason if you click fast enough like this, the block loses its status of being selected. @talldan forgive the direct ping, I know you're so busy — but do you have any insights as to whether this might be related to some of the recent navigation block selection issues we had?

@jasmussen
Copy link
Contributor

Actually scratch that, I might be able to fix this one.

@jasmussen
Copy link
Contributor

Fix here: #30169

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Mar 24, 2021
@talldan
Copy link
Contributor

talldan commented Mar 24, 2021

However for some reason if you click fast enough like this, the block loses its status of being selected. @talldan forgive the direct ping, I know you're so busy — but do you have any insights as to whether this might be related to some of the recent navigation block selection issues we had?

Sorry, missed the ping. Looking at the video, I though it might be the page scrolling across that caused one of the clicks to miss and instead click the editor canvas. But sounds like you found another root cause.

@jasmussen
Copy link
Contributor

I did. 30169 should address this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants