Block Editor: Reset inspector tab when selecting non-list-view content item#75656
Block Editor: Reset inspector tab when selecting non-list-view content item#75656
Conversation
|
Size Change: +230 B (0%) Total Size: 6.84 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 4f28c76. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22168467219
|
|
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. |
Thanks for testing. I'll take a look 👀 |
1a3b66f to
8e0fb02
Compare
|
I'll keep this one simmering and see if I can crack something that's consistent. Might need more thorough testing. Cheers! |
|
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
List child selection while on Content tab → switches to List View
Intentional List View switches are preserved (not undone by reset)
No-op scenarios (tab stays where it is)
|
| } | ||
| const parentName = getBlockName( parentId ); | ||
| if ( | ||
| parentName === 'core/navigation' || |
There was a problem hiding this comment.
Tech debt alert. There's probably a very good reason why the navigation block doesn't support supports: { listView: true }. I need to remind myself why
There was a problem hiding this comment.
It was the first block to implement the List View inspector UX, and because of that it has its own custom implementation rather than using the proper block support.
A couple of parts work slightly differently on the nav block List View like the appender and settings menu, so it hasn't been possible to make the block use the block support.
86e6719 to
c5dd1aa
Compare
…t item When editing a pattern, clicking a list-view-enabled block (e.g. Button) in the content list switches the inspector to the List View tab. Selecting a different block without list view support (e.g. Heading) left the tab stuck on List View because the section block clientId never changes, so the existing tab reset logic never fired. Add a selector that detects when the selected block is a content item that doesn't navigate to List View, and an effect that switches back to the Content tab in that case. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The clientId-based reset for the "Edit navigation" case was not visibly different from the existing fix. Reverting to keep only the shouldResetToContentTab transition logic. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace the previous approach that only reset the tab for non-list-view blocks with a simpler one that resets to Content whenever any content block is selected while on List View. This handles the case where clicking a list-view-enabled block (e.g. Buttons) via the canvas should also return to the Content tab. A skipNextContentResetRef prevents the reset from firing when switchToListView or requestInspectorTab intentionally opened List View for that same block (content list click-through and "Edit navigation"). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When a child of a list-view-enabled content block is selected (e.g. clicking Button 1 inside a Buttons block in the canvas), auto-switch to the List View tab. This makes the inspector tab behavior consistent regardless of whether the child was selected via the list view panel or directly in the canvas. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Set hasUserSelectionRef to true (not false) when programmatically switching to List View for a list child. This prevents the auto-select effect from immediately resetting back to the first tab (Content). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When auto-switching to List View for a selected list child, also call setOpenListViewPanel with the parent block's clientId and increment the expand revision. This ensures the correct panel expands and the selected child block is visible in the list view. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove redundant prev-ref guards from inspector tab effects
…n in the state selection. This change ensures that the anchor element is re-queried after the PrivateListView remounts, improving the accuracy of the displayed content in the list view.
This commit introduces a new test suite for the pattern inspector tabs in the block editor. It includes tests for resetting the inspector tab when selecting non-list-view content blocks, maintaining the List View tab selection, and auto-switching to the List View when interacting with list children. These tests ensure consistent behavior of the inspector UI across different interaction scenarios.
0b7ef83 to
f98d3e1
Compare
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Summary
clientIdnever changes, so the existing tab reset logic never firedfalse → truetransitionRelated
Testing Instructions
Test plan
requestedTabare not affectedKapture.2026-02-20.at.15.34.24.mp4
Navigation block (inside a template part)
Kapture.2026-02-20.at.16.09.29.mp4