Child blocks are displayed in the block inserter and block visibility doesn't work

[t-hamano]

What problem does this address?

I found two issues in the trunk:

• Child blocks that have a specific parent, such as the List Item, are displayed. When you click on the block, it will say "Block "{blockName}" can't be inserted.". (This may be a new specification)
• "Manage block visibility" doesn't work.

I used git bisect and it looks like this issue occurred in #65490.

957141419a3cef7be97099ce0c69e8f8.mp4

cc @youknowriad @andrewserong @jorgefilipecosta

[youknowriad]

Thanks for catching the bug and creating the issue. It seems the new behavior to "compute insertion point" on the fly should only apply to specific conditions, not all the conditions of when a block is visible or not.

So it's like we need two different kind of selectors:

• Can insert block
• Is block visible

I'll explore something.

[youknowriad]

We should have e2e tests about the "manage block visibility" thing

[Mamaduka]

I think the #65700 only partially resolved the issue.

Child blocks that have a specific parent, such as the List Item, are displayed. When you click on the block, it will say "Block "{blockName}" can't be inserted.". (This may be a new specification)

This one remains. All child blocks are visible for the default root. The child blocks are no longer displayed when I select any container block, which causes a somewhat expensive re-render.

Screencast

CleanShot.2024-11-05.at.17.35.01.mp4

[t-hamano]

All child blocks are visible for the default root. The child blocks are no longer displayed when I select any container block, which causes a somewhat expensive re-render.

This is indeed a strange behavior. However, I remember that there was an effort to show all blocks in #62169. Should all blocks, including children, be shown in a container block?

[Mamaduka]

After #62169, you see all blocks in the inserter. When container sets allow children, they're displayed at the top, followed by the remaining blocks. Click on rest (non-allowed in the container) blocks; insert those after the container.

I think the current behavior for the default root ID ( ' ' ) is a bug.

@ellatrix, @youknowriad, what do you think?

[youknowriad]

I agree, that ideally child blocks should only appear if you're within the parent (not necessarily directly, but at least it's an ancestor to the current selection)

[Mamaduka]

Should I re-open this issue or create a new one?

[youknowriad]

Let's reopen it.

[annezazu]

Noting that I just got reports of the same problem (I think) reported here with the buttons & button blocks:

bug.in.buttons.mov

For 6.6, we only show "buttons" I imagine to preserve the parent/child relationship and provide a better UX for styling:

[Mamaduka]

I just noticed that the behavior of the inserter items is broken for every rootClientId that doesn't limit blocks.

I'll prioritize working on a fix for this bug.

[talldan]

This bug caused confusion in the latest WordPress speed build 😬

[jeryj]

Instead of hiding blocks that can't be inserted at that level, what if we leave the block visible and add the necessary wrapping blocks to insert it?

So, if someone selects Column from the inserter and there's no wrapping Columns block, add a Columns block with a Column block within it.

[youknowriad]

Instead of hiding blocks that can't be inserted at that level, what if we leave the block visible and add the necessary wrapping blocks to insert it?

That's a decent idea but IMO, we don't know enough to make the right call. While it can work for "column" and "block". I don't see anyone inserting "query pagination" and having a "query" around it or something like that.

[jeryj]

Good point. But for other blocks it could be really helpful, like "Instagram" could add the social icons wrapping block for it. Otherwise you have to know to search for "social icons" first.

That said, this may guide you to even less of an understanding of how it works. You may end up with a different social icons block for each icon 😅