-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
Describe the bug
Related #18100
This is a very niche issue and hard to explain, but one that might become apparent if we start using the block navigator more.
#18100 introduces a block appender in the navigator:

The issue experienced is that If a user accesses the navigator before InnerBlocks had rendered and then clicked an appender, the user could insert any type of inner block, despite there being allowedBlocks defined on InnerBlocks.
The issue was that the InnerBlocks component had some conditional rendering:
gutenberg/packages/block-library/src/navigation-menu-item/edit.js
Lines 196 to 201 in 3d6392d
| { ( isSelected || isParentOfSelectedBlock ) && | |
| <InnerBlocks | |
| allowedBlocks={ [ 'core/navigation-menu-item' ] } | |
| renderAppender={ hasDescendants ? InnerBlocks.ButtonBlockAppender : false } | |
| /> | |
| } |
If for any reason the component wasn't rendered before accessing the navigator, allowedBlocks wouldn't work as registration of those allowed blocks is dependent on the component mounting.
Questionable whether this is considered a flaw or a bug in the block implementation, but it's something that can't really be policed for third party blocks and could cause some very unusual issues for users creating posts.