Pattern Overrides: Parent selector not visible in toolbar when overridable block is selected

[artemiomorales]

Description

When overrides are enabled in a pattern and an overridable block is selected, the parent selector is not visible in the block toolbar, which is unexpected.

Reported by @annezazu in #59477 (comment).

Step-by-step reproduction instructions

1. Create a new synced pattern
2. Add a paragraph to the pattern
3. Enable instance overrides for the paragraph beneath 'Advanced' by giving it a name
4. Save the pattern and insert it into a post
5. Select the overridable paragrah — see that the parent selector in the toolbar is not visible.

Screenshots, screen recording, code snippet

parent.block.mov

Screen.Recording.2024-03-05.at.9.40.45.AM.mp4

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

[youknowriad]

I'm actually wondering if the current behavior is the right now. AFAIK we want to treat the whole pattern as a single block (like the content-only), so no "parent selector" but I could be wrong. Let me know what you think @jasmussen @jameskoster Is this valid or should we close it?

[jasmussen]

The latest approach for contentOnly is indeed to treat any pattern as "contentOnly locked", that is as if it was a single block you interact with. In fact there's a type of overrides built right into regular patterns, insofar as all their contents are editable.

One of the aspects of "synced pattern overrides" as it was discussed, was the ability to have that same thing, only the overrides were local: you'd build a basic synced pattern, but every editable piece would be surfaced as editable locally, without saving to the source. There's a lot of overlap with what block bindings can do here, and UI wise there's an opportunity to connect all of these pieces in the content panel.

I don't know if that fully answers your question, but I do think it validates that not showing the parent block selector is intentional. But a quick CC to @fcoveram who has also had thoughts on this.

[fcoveram]

In fact there's a type of overrides built right into regular patterns, insofar as all their contents are editable.

Yes.

…I do think it validates that not showing the parent block selector is intentional.

Not sure why the editable property of content invalidates selecting the parent block. Those are two separated actions.

It is more strange that selecting a child block keeps showing edit tools of siblings in both sync and not sync patterns.

Not synced	Sync

[jasmussen]

I think you are touching on something delicate there: in block editing, selecting any block surfaces the block toolbar (with a parent button if need be), and updates the inspector to be contextual to that block. In pattern editing, you don't show the parent selector (at present) and the inspector is not "child block" contextual. That's because conceptually, you are editing a single block. So arguably the disconnect here is that we show the editable fields inside this conceptually-one-block, in the list view. That is a compromise, and one I'm personally okay with, but I feel that is the odd piece out, and from a certain mindset it could be argued that it should show as a single block in the list view.