Navigation Block: fix link UI popover only opens if there's one navigation block in the page

[MaggieCabrera]

Description

While fixing #47828 we uncovered a new bug in the case where more than one navigation block is present on the page.

Step-by-step reproduction instructions

Insert a navigation block with custom links.
Click the inserter to add a new custom link, it should trigger the popover to edit the link.
Insert a new navigation block just below.
Insert a new custom link to it. The popover should open, but it doesn't.

Screenshots, screen recording, code snippet

Environment info

No response

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

[getdave]

Problem

We have x2 Navigation blocks which are both referencing the same underlying wp_navigation entity. Therefore changing items in Nav block 1 will automatically see those changes reflected in Nav block 2 via syncing with the entity.

When a link block is inserted into menu 1 the lastBlockInserted state reflects that link block which exists in menu 1 (and nav block 1).

But then immediately after that Nav block 2 syncs with the entity which triggers REPLACE_INNER_BLOCKS which causes the state for lastBlockInserted to update to reflect the synced blocks and not the block that was manually inserted by the user.

What we want is for the user changes only to be reported as the "last block updated" whereas what's happening is the synced blocks are reported. This means that the following check will never pass...

gutenberg/packages/block-editor/src/components/off-canvas-editor/block-contents.js

Line 80 in b071855

clientId === lastInsertedBlockClientId &&

...and thus and Link UI is never shown in the list view.

Possible Solutions

Add "actor" metadata

In #47874 we considered adding a actor to the metadata associated with the REPLACE_ and INSERT_ actions and storing that in the lastInsertedBlock state. We then thought we'd attach an actor of user to any actions triggered by a user (i.e. using the inserter) and an actor of auto to any actions triggered automatically (e.g. useBlockSync).

The idea was that we'd grab the meta from the state and discard any results that were triggered by auto actors. However this won't work because the state is wiped out for each new action, meaning if you discard auto then you can't continue looking "back" in the state for blocks inserted by user because these have been removed by subsequent actions.

Other ideas

• Maybe have the state store all the blocks that have been inserted for the current editor session. Then traversing history to look for the last block inserted matching a given actor would be possible.

[scruffian]

I think this bug is a manifestation of the fragile nature of the solution we have here. I don't love the current UX for adding links to a navigation block - I think that the idea being explored in #46981 is a superior UX and we should explore this direction.

This bug only happens in quite a specific scenario (you need to have the same nav block twice in the same page) and even then it doesn't stop you from being able to edit the block - it just requires a few extra clicks - you could even argue that it's a better experience than the current one!

All that is to say I think we should pause these efforts and put them into #46981.

[scruffian]

I don't think this is anything to do with lastInsertedBlockClientId. When I remove this line, the problem goes away:

gutenberg/packages/block-library/src/navigation-link/edit.js

Line 234 in 7d8c488

setAttributes( { isTopLevelLink } );

[scruffian]

I think we can solve this a different way: #48219