Enable overlay for Navigation block in contentOnly mode to support sidebar editing workflow

[getdave]

What

In contentOnly mode, the Navigation block needs an active overlay that ensures clicks within the Navigation block select the parent Navigation block itself, rather than immediately selecting child Navigation Link blocks.

Currently, overlays are disabled for blocks in contentOnly mode based on the assumption that "if the mode is 'contentOnly' then the overlay is redundant since there will be no controls to interact with once selected." However, the Navigation block has more complex requirements that need the overlay to function properly.

Current behavior:

1. Navigation block is in contentOnly mode
2. Click anywhere within the Navigation block
3. First click selects a child Navigation Link block (not the parent Navigation block)
4. Editable List View editing experience in sidebar doesn't activate
5. User cannot immediately access Navigation-level editing tools

Expected behavior:

1. Navigation block is in contentOnly mode with overlay enabled
2. Click anywhere within the Navigation block
3. First click selects the parent Navigation block
4. Editable List View editing experience appears in the sidebar
5. Second click on a specific Navigation Link allows drilling down to that child block

Why

The Navigation block uses a sidebar-based editing experience (specifically the Editable List View) that is only active when the Navigation block itself is selected. When a Navigation Link child block is selected instead, the sidebar shows controls for that individual link (see #74895 for enabling these controls) rather than the overall navigation structure.

To support the intended "off canvas" editing workflow where users see the Editable List View in the sidebar when interacting with the Navigation block, we need the overlay to ensure that the first click selects the Navigation block parent. This allows users to see the full navigation structure in the Editable List View before drilling down into individual items.

Without the overlay, users cannot easily access the Navigation block's primary editing interface (the Editable List View), which is essential for managing menu structure and hierarchy.

How

There are two potential routes to solve this issue:

Option 1: Create a general API (preferred long-term solution)

Implement a mechanism to allow blocks to opt into overlays in various editing modes, rather than globally disabling overlays for all contentOnly blocks.

Make blockOverlay an opt-in block support that can be configured per editing mode:

blockOverlay: {
    default: false,
    contentOnly: true
}

This would allow the Navigation block to opt into overlay behavior specifically in contentOnly mode, with sensible fallbacks for any keys not provided (e.g., disabled mode).

This approach avoids adding block-specific conditional statements in core code and provides a flexible mechanism for other blocks with similar requirements.

Option 2: Navigation-specific short-term workaround (most feasible for 7.0)

Implement a targeted workaround specifically for the Navigation block that enables overlay in contentOnly mode. This would be:

• Faster to implement and test for the 7.0 release timeline
• Lower risk as it's scoped to a single block
• Does not incur significant technical debt
• Can be replaced later with the general API (Option 1) when time permits

Option 2 is likely the most pragmatic choice for WordPress 7.0, allowing the Navigation block to function properly in contentOnly mode while deferring the broader API work to a future release.

Acceptance Criteria

• Overlay is enabled for Navigation block when in contentOnly mode
• First click on Navigation block (in contentOnly) selects the parent Navigation block
• Editable List View editing experience appears in sidebar when Navigation block is selected
• Second click on a Navigation Link allows drilling down to that child block
• Implementation chosen (Option 1 or Option 2) is clearly documented
• If Option 1 is chosen: Implementation uses block supports and is extensible for other blocks
• If Option 2 is chosen: Workaround is scoped to Navigation block and doesn't create significant technical debt

User Stories

As a user, I want clicking on the navigation menu to show me the Editable List View in the sidebar, so I can see and manage the full navigation structure before editing individual items.

As a user, I want a consistent way to access Navigation-level editing tools, so I can work with the overall menu structure rather than accidentally selecting individual links.

As a user, I want to be able to drill down to individual navigation items when needed, so I can edit specific link properties after viewing the overall structure.

Technical Reference

• Current code: overlay is disabled for blocks in contentOnly
• Assumption to revisit: "If the mode is 'contentOnly' then the overlay is redundant since there will be no controls to interact with once selected"

Screencapture

Demo using #71747:

Screen.Capture.on.2025-09-19.at.10-14-56.mp4

Related Issues

• Navigation block should show List View tab when user shows intent to edit navigation structure #74894 - Navigation block should show Editable List View tab when user shows intent to edit navigation structure
• Enable sidebar inspector controls for Navigation Link blocks selected in List View #74895 - Enable sidebar inspector controls for Navigation Link blocks selected in Editable List View
• Ensure "Edit Navigation" action is available and automatically selects Navigation block across all editor contexts #73383 - Ensure "Edit Navigation" action is available and automatically selects Navigation block
• Try adding content roles to navigation blocks #71747 - Original PR demonstrating this behavior

[getdave]

I have a Nav block specific fix for this in #72248.

The selector us currently unstable and we don't have time to stablise it and refine the API prior to 6.9.

As a result I propose merging the fix above and then refining post-6.9.