Stay in the selected inspector tab when switching blocks

[yscik]

Fixes #51104

What?

• In the sidebar inspector, keep track of the tab (Settings/Styles) the user selects
• When selecting a new block, open the last selected tab by default

Why?

When building a template, it's common to go back and forth between blocks to adjust the same settings, like margins or other spacing. Having to navigate to the controls again and again is a source of friction.

How?

• Introduce a hook, useLastSelectedInspectorControlTab
• Stores the last selected tab in the settings state of the block editor store
• Hook this up to the TabPanel's initialTabName and onSelect props.

Testing Instructions

• Open a template for editing in the site editor that contains multiple blocks
• Select a block, open the sidebar inspector, and select the Styles tab
• Select another block, and check that the Styles tab remains open
• Select a block that doesn't have a Styles tab, and make sure a default tab is still selected (Settings/List)

Testing Instructions for Keyboard

• Changes shouldn't affect keyboard navigation

Screenshots or screencast

Gutenberg-remember-sidebar-tab.mov

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Focus] Accessibility (a11y), [Feature] UI Components.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[alexstine]

I warned very early on about PRs like this for accessibility reasons. Some questions.

1. What happens if a block doesn't have the same tabs?
2. How do you communicate that to users with no vision who will expect the same tab to be selected from the last block? Visually, you can quickly see this. If a user without vision expects the same tab to be selected and it is not, they might explore the tab content before realizing it and returning to the tab panel to go elsewhere.

Always defaulting to the same tab offers all users a very predictable experience even though it may require an extra click at times.

Thanks.

[joedolson]

This kind of comes down to a workflow issue. If your workflow is the one described - configure one type of setting sequentially for each block, then this is an improvement. If, on the other hand, your workflow is to fully configure each block as you go, then this is worse. I think we should prefer predictability (always opening the same tab) over presupposing a particular workflow.

[hanneslsm]

Would it make sense and is possible to set a default in the preferences? I, as a theme creator for example, would rather always have the styles tab open by default and are willing to accept extra clicks for opening the block settings.

[hanneslsm]

Would it make sense and is possible to set a default in the preferences? I, as a theme creator for example, would rather always have the styles tab open by default and are willing to accept extra clicks for opening the block settings.

We already have a preference for the list view.

Always open list view
Opens the block list view sidebar by default.

I could imagine a similar one for the block tab, like

Always open style tab
Opens the block styles tab by default.

---

I think we should prefer predictability (always opening the same tab) over presupposing a particular workflow.

@joedolson In general tend to agree with you. However, currently it feels like as if you were in the kitchen and every time you want to cut something you have to get a knife out of the drawer. And as you know, when cooking you'll use the knife a lot. I don't think this is a particular workflow, but essential for using the block editor.
Staying in the same tab would dramatically improve the UX of the editor, so we definitely should try to find a solution that improves the UX and is accessible.

[alexstine]

@hanneslsm Adding a preference would be an acceptable compromise but the least inaccessible option cannot be selected by default. Thanks.