InnerBlocks allowedBlocks does not remove non-whitelisted blocks

[getdave]

In testing a bug with the Navigation block I came upon a situation whereby a Navigatino block could be rendered inside a Navigatino block.

This happens because the Nav block primarily uses controlled inner blocks. If those blocks contain a Navigation block then it appears it is rendered.

The Nav block sets the allowedBlocks property on useInnerBlocksProps which updates the block list settings with a small subset of blocks that are allowed inside the Nav block. Despite this however, the Nav block is still included in the inner blocks of the Nav block.

I cannot find anywhere in the code where allowedBlocks is applied to the block list. It is used to filter the items in the inserter but that seems to be it.

I'd like to confirm:

• this is a bug
• that we ought to update allowedBlocks to take a more active role in filtering the block list

[getdave]

FYI you can replicate this situation by following the test instructions in #46279 and then going to the Editor.

[skorasaurus]

might be a dupe of #15682 ?

[getdave]

#15682

Thanks. I took a quick look.

I think this [46281] one is distinct in that I'm saying the allowedBlocks prop of InnerBlocks doesn't behave as I expect, rather than I can't filter the value.

[talldan]

I think this is similar to the discussion in #25787, although a different case.

allowedBlocks prevents insertion using the UI, but there are ways to circumvent it in the same way it's possible to work around adding a classic block to a reusable block.

The lengths a user has to go to in order to add a nav block in a nav block are much more extreme though, and my feeling is that if a user feels advanced enough to do that they should also be advanced enough to deal with the repercussions of making a mistake.

If it's a bad enough situation then I guess some custom code could be added to the nav block on the editor side, which I think could be similar to the recursion provider idea (bypass rendering of the block and show an error instead).

[getdave]

Thanks @talldan. Having spoken with @jorgefilipecosta in a DM on Slack I now understand this to be the case. I agree it's a pretty major edge case. We should be easily able to detect a core/navigation block in the edit code but not sure if it's worth the effort unless this comes up regularly.

Hopefully @jorgefilipecosta can add some more context about allowedBlocks here but for now I'm closing this one out.