Block Editor: Keep the inspector tab in step with the content selection

[ramonjd]

What?

This PR syncs the block inspector's tab item selection with the list view, and makes sure what's selected in the list view, canvas and in the block inspector match.

Selecting a block in any of the three now shows it in the other two, including which inspector tab and which List View panel is open.

Related

• Gallery: Add list view block support #75407 (comment)

Why?

Selection is already shared between the canvas and the left hand sidebar List View.

The inspector was the odd one out. It held whichever tab it was last left on, so the selected block was often not the one the inspector was showing.

For example, in trunk, selecting a child item from a Button or List block in the content tab didn't select the corresponding block in the list view.

Similarly, clicking away from a child block to a higher block in the list view didn't update the block inspector list.

See the "Before" screencast below.

How?

"List View tab" below means the tab in the block inspector on the right, not the Document Overview on the left.

• The inspector now watches which block is selected. Before, it only noticed when you moved to a different pattern, which is why the tab could get stuck.
• Select something nested inside one of the pattern's items, like a Button inside Buttons, and the inspector opens its List View tab with that item expanded.
• Select one of the pattern's items directly and the inspector goes back to its Content tab.
• Deliberately switching tabs still wins. Clicking an item in the Content list, or "Edit navigation", is not undone by the two rules above.
• Fixes the small popover in the List View tab losing its position when that list redraws.
• Adds one private selector getListViewSupportAncestor, to work out which item a selection sits inside.

Testing Instructions

1. Create or insert a pattern that has buttons/lists and some headings or paragraphs.
2. Add it to a post and select a block inside it to enter content-only editing.
3. In the inspector's Content tab, click the Buttons item. The tab switches to List View.
4. Click the Heading on the canvas. The tab switches back to Content.
5. Click a Button on the canvas. The tab switches to List View with the Buttons panel open and that Button selected.
6. Click the Content tab, then select the other Button on the canvas. The
   tab switches back to List View.
7. Click the List View tab directly. It stays selected.

Before

Kapture.2026-04-16.at.14.38.32.mp4

After

Kapture.2026-04-16.at.14.37.31.mp4

Navigation block (inside a template part)

The Navigation block is a special case: it always offers a List View, regardless of how its menu is locked or populated. It is also the block reached by the "Edit navigation" toolbar button, which asks for a specific
inspector tab and panel.

Kapture.2026-02-20.at.16.09.29.mp4

Alternative approach

#83048 is a draft that derives the tab from the selection rather than correcting it with effects. It removes the suppression flags this PR adds, but it is a larger change that replaces existing coordination. Opened for comparison, not as a replacement.

Use of AI Tools

Claude (via Claude Code) was used to help implement this change, write its tests, and draft this description. All of it has been reviewed by me and I take responsibility for it.

Follow-ups

• ListViewPanel (hooks/list-view.jsx) and BlockCard each work out whether a block sits inside another List View block with their own getBlockParents( …, false ).find( shouldRenderBlockListView ) lookup. They could call getListViewSupportAncestor instead. Left for a separate PR to keep this one focused.

[github-actions]

Size Change: +372 B (0%)

Total Size: 7.72 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	422 kB	+372 B (+0.09%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in e79b003.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29392009273
📝 Reported issues:

• [Flaky Test] should allow user to add and remove multiple local font files #78760 in /test/e2e/specs/admin/font-library.spec.js
• [Flaky Test] two users concurrently move list items (RTC WebSocket) #79951 in /test/e2e/specs/editor/collaboration/collaboration-stress.spec.ts

[talldan]

This works well. I thought that maybe it'd also select the list view tab when selecting one of the blocks that's shown there, but it doesn't. So it's a lot more minimal than I expected, and that might be a good thing this close to beta. 😄

I tested the 'Edit navigation' button changes from Navigation: select list view tab on contentOnly. Alternative with explicit solution, and that still works. However, if you click 'Edit navigation' and then select a different block that doesn't have list view support, the List View tab still remains open, so the behavior feels a bit inconsistent there.

[ramonjd]

However, if you click 'Edit navigation' and then select a different block that doesn't have list view support, the List View tab still remains open, so the behavior feels a bit inconsistent there

Thanks for testing. I'll take a look 👀

[ramonjd]

I'll keep this one simmering and see if I can crack something that's consistent. Might need more thorough testing.

Cheers!

[ramonjd]

I'm listing some preliminary scenarios (need validating) to handle so I can come back to test:

Content block selection while on List View → switches to Content tab

1. Click Buttons in content list → List View, then click Heading in canvas → Content
2. Click Social Links in content list → List View, then click Paragraph in canvas → Content
3. Click Buttons in canvas while on List View → Content (previously stayed stuck on List View)
4. “Edit navigation” → List View, then click Heading in canvas → Content
5. requestInspectorTab('list') → List View, then select any content block → Content

List child selection while on Content tab → switches to List View

6. Click Button 1 (child of Buttons) in the canvas while on Content → List View
7. Click a Social Link (child of Social Links) in the canvas while on Content → List View

Intentional List View switches are preserved (not undone by reset)

8. Click Buttons in content list → switchToListView sets skipNextContentResetRef → stays on List View
9. Click Social Links in content list → same skip mechanism → stays on List View
10. “Edit navigation” → requestedTab effect sets skipNextContentResetRef → stays on List View

No-op scenarios (tab stays where it is)

11. Click Heading while already on Content → stays on Content (same role, no transition)
12. Click Button 1 then Button 2 in list view → stays on List View (isListChildSelected stays true)
13. Click Buttons in content list then Social Links in content list → both use switchToListView, stays on List View
14. Manually click List View tab → stays on List View (no block change triggers the effect)
15. Manually click Settings/Styles tab → not affected (effects only switch between Content and List View)

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ramonjd]

However, if you click 'Edit navigation' and then select a different block that doesn't have list view support, the List View tab still remains open, so the behavior feels a bit inconsistent there.

Sorry I forgot to reply to this. I just retested according to the steps in #75578

Kapture.2026-03-06.at.11.22.51.mp4

Are you still seeing the list view tab remaining open, or am I looking in the wrong place?

[ramonjd]

Not sure if this one is still required, but I'll keep it rebased just in case - it fixes the block inspector getting stuck on the List View tab while editing a pattern, but it tracks the selected tab as state with lots of effects and flags to track things.

#83048 is a draft alternative - it derives the tab from the selection instead, so the flags aren't needed.

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: +317 B (0%)

Total Size: 8.21 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	500 kB	+317 B (+0.06%)

_{483230d Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	6c4dcbc	trunk	% Change
timeToFirstByte	54.9 ms +13.48% -3.01%	54.4 ms +15.35% -2.48%	0.92%
largestContentfulPaint	98 ms +2.04% -10.2%	96 ms +0% -4.17%	2.08%
lcpMinusTtfb	35.15 ms +22.05% -6.4%	40.05 ms +7.12% -18.1%	-12.23%
wpBeforeTemplate	27.18 ms +12.69% -1.62%	26.71 ms +21.56% -1.31%	1.76%
wpTemplate	23.55 ms +4.46% -3.31%	23.2 ms +4.35% -2.07%	1.51%
wpTotal	51.11 ms +12.23% -3.42%	50.63 ms +14.54% -2.57%	0.95%
wpMemoryUsage	7.53 MB +0% -0%	7.49 MB +0% -0%	0.45%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	6c4dcbc	trunk	% Change
timeToFirstByte	40.3 ms +9.55% -1.74%	43.85 ms +4.9% -1.48%	-8.1%
largestContentfulPaint	88 ms +6.82% -0%	96 ms +2.08% -0%	-8.33%
lcpMinusTtfb	48.4 ms +0.72% -0.83%	52.65 ms +0.95% -1.14%	-8.07%
wpBeforeTemplate	23.74 ms +8.89% -1.47%	23.15 ms +2.29% -0.65%	2.55%
wpTemplate	13.36 ms +5.69% -1.2%	17.49 ms +1.49% -2.06%	-23.61%
wpTotal	37.3 ms +9.52% -1.39%	40.69 ms +5.53% -1.43%	-8.33%
wpMemoryUsage	6.01 MB +0% -0%	6.11 MB +0% -0%	-1.67%
wpDbQueries	10 +0% -0%	14 +0% -0%	-28.57%

media-processing

Metric	6c4dcbc	trunk	% Change
mediaProcessingJpeg	413.23 ms +0.74% -1.03%	406.82 ms +2.49% -0.43%	1.58%
mediaProcessingAvif	6267.7 ms +0.06% -0.15%	6178.24 ms +0.02% -0.2%	1.45%
mediaProcessingJpegToAvif	4312.05 ms +0.31% -0.1%	4306.74 ms +0.18% -0.24%	0.12%

media-upload

Metric	6c4dcbc	trunk	% Change
jpegUploadProcessing	1459.27 ms +33.29% -2.7%	1412.13 ms +1.46% -0.92%	3.34%
pngUploadProcessing	196.41 ms +14.37% -2.83%	206.2 ms +4% -4%	-4.75%
largeJpegUploadProcessing	1412.92 ms +1.87% -1.09%	1401.8 ms +1.67% -0.65%	0.79%
multipleImageUploadProcessing	1528.25 ms +9.31% -1.04%	1549.43 ms +2.88% -1.23%	-1.37%

post-editor

Metric	6c4dcbc	trunk	% Change
serverResponse	425.14 ms +2.72% -8.43%	402.39 ms +8.93% -8.24%	5.65%
firstPaint	235.82 ms +14.94% -16.56%	243.52 ms +22.45% -27.21%	-3.16%
domContentLoaded	1073.89 ms +2.51% -2.61%	1071.06 ms +1.19% -1.66%	0.26%
loaded	1075.01 ms +2.52% -2.59%	1072.4 ms +1.17% -1.65%	0.24%
firstContentfulPaint	449.55 ms +2.91% -4.89%	437 ms +4.1% -1.18%	2.87%
firstBlock	3126.95 ms +0.94% -0.41%	3127.51 ms +0.69% -0.89%	-0.02%
type	21.35 ms +2.58% -5.53%	20.81 ms +3.8% -6.34%	2.59%
typeWithoutInspector	20.26 ms +6.91% -2.52%	21.05 ms +1.66% -6.32%	-3.75%
typeWithTopToolbar	24.78 ms +3.03% -2.54%	26.5 ms +3.21% -4.64%	-6.49%
typeContainer	8.92 ms +13% -10.76%	8.59 ms +9.55% -3.38%	3.84%
focus	74.05 ms +2.97% -5.13%	75.69 ms +15.62% -6.13%	-2.17%
firstFocus	205.68 ms +0% -0%	207.38 ms +0% -0%	-0.82%
selectAll	490.18 ms +0.91% -3.83%	490.11 ms +3.15% -2.43%	0.01%
listViewOpen	70.53 ms +4.01% -8.83%	68.86 ms +7.03% -8.18%	2.43%
inserterOpen	23.73 ms +7.75% -4.85%	23.73 ms +9.36% -8.64%	0%
inserterHover	2.91 ms +9.97% -5.15%	3.15 ms +7.94% -6.03%	-7.62%
inserterSearch	8.39 ms +5.01% -11.08%	8.36 ms +2.27% -4.19%	0.36%
loadPatterns	657.78 ms +3.74% -5.74%	668.6 ms +2.36% -10.4%	-1.62%
wpTotal	414.28 ms +2.62% -8.79%	391.09 ms +9.19% -8.55%	5.93%
wpMemoryUsage	13.07 MB +0% -0%	13.03 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	6c4dcbc	trunk	% Change
serverResponse	285.99 ms +2.37% -9.25%	283.21 ms +0.53% -3.45%	0.98%
firstPaint	192.44 ms +62.99% -27.05%	141.16 ms +17.75% -9.42%	36.33%
domContentLoaded	767.42 ms +1.71% -1.19%	731.77 ms +3.26% -1.87%	4.87%
loaded	768.32 ms +1.7% -1.19%	732.52 ms +3.27% -1.87%	4.89%
firstContentfulPaint	310.9 ms +6.48% -3.34%	304.67 ms +4.35% -5.2%	2.04%
firstBlock	2769.64 ms +3.21% -3.04%	2634.22 ms +2.03% -0.88%	5.14%
type	16.23 ms +7.39% -3.39%	15.99 ms +2.56% -2.63%	1.5%
navigate	91.94 ms +7.83% -0.99%	90.9 ms +6.04% -6.79%	1.14%
loadPatterns	891.12 ms +2.26% -2.59%	1035.44 ms +12.02% -10.85%	-13.94%
loadPages	973.38 ms +0.91% -1.22%	964.74 ms +1.36% -0.89%	0.9%
wpTotal	278.68 ms +2.5% -9.48%	275.83 ms +0.48% -3.5%	1.03%
wpMemoryUsage	12.02 MB +0% -0%	11.97 MB +0% -0%	0.4%
wpDbQueries	44 +0% -2.27%	44 +0% -0%	0%

_{483230d Run}

[talldan]

@ramonjd Honestly, I think the PR description is a little lacking in the usual details that PR descriptions have. No linked issue so there's a lot of context missing.

I think I also mentioned in private that folks that work on the nav block should be pinged for review, as they implemented some of this code for the nav block, and might like to check that this still works as expected.

Giving this a re-test, and it does work nicely, so no reason it can't be shipped.

[ramonjd]

Honestly, I think the PR description is a little lacking in the usual details that PR descriptions have. No linked issue so there's a lot of context missing

Thanks @talldan

It's very stale this one, so just wanted to see if it still worked after a rebase.

You're right. I'll update the PR desc to explain what's going on and why a bit better, and see what other folks think.

There is no issue for this - I remember noticing the inconsistency back in the original pattern editing days.

I can create one if it helps

[talldan]

No issue is fine, a good PR desciption can make up for a lack of issue 👍

[ramonjd]

Added @getdave as a reviewer just to make sure nothing funny is happening when selecting navigation blocks either in patterns or templates (I checked both).

This PR uses shouldRenderBlockListView which 'core/navigation' always returns true for.

2026-09-17.13.36.09.mp4

[talldan]

It works pretty well for me when tested.

The comments are mostly nits, but feel a bit more important than normal with the way the code is quite complex.

[talldan]

The selector can in the future be called from other code too and used for other purposes, so I think this part of the doc block isn't needed.

[fcoveram]

The interaction feels coherent ✨

When a block is selected from the List View panel, Canvas, or the Inspector tab (Content and List View), the active selection should be communicated across all three UI regions. Each area not only highlights the current selection but also offers actions specific to its region.