Preserve selection when switching block editor tabs

[draganescu]

Describe the bug
This is probably an intended feature, but when switching tabs in the editor sidebar between document and block, the current block selection is lost.

The problem is easily recoverable on desktop, but it presents an almost empty screen on mobile, looking like an error.

To reproduce
Steps to reproduce the behavior:

1. Selet a block
2. Show the sidebar
3. Click on Document
4. Click on Block
5. No block is selected so this panel is now empty

Expected behavior
I expect the selection to be preserved because there is nothing I did to it by fiddling with the sidebar's tabs.

[draganescu]

@mapk @jasmussen since fixing this is a matter of simply not clearing the selection anymore, by removing a single call to clearSelectedBlock() in the openDocumentSettings() handler of the Document Tab click, it seems to not be a technical need, so I wonder why is this interaction like this?

@jorgefilipecosta is there any technical reason to clear the block selection?

[draganescu]

@mtias and @jasmussen for posterity, here is a sum up of what we discussed:

• we need to have the blocks selected when we switch back to the block tab in the inspector. I propose that instead of building a mechanism to restore selection, we simply don't clear it anymore.

The argument is this:

• the main reason deselection happens is because clicking the document tab is conceptually similar to clicking on the canvas, hence deselecting everything.
• the other reason deselection happens is because the tabs are similar to breadcrumbs and clicking on the document is similar to moving selection to one level left in the breadcrumb bar.

My opinion is that:

• while the [ document tab == canvas ] principle is real, implementing it results in a bad experience. The worst of it is on small screens where switching inspector tabs results in an empty page, if returning to the block tab. While the principle is true, the reality of it should be that we do what is best for the user.
• the breadcrumbs reason doesn't hold because we have tabs today and tabs are not hierarchical when they're on the same level. Simply put switching inspector tabs should not do anything to the document, including clearing the block selection.

Another thing that popped up in discussion is being future proof: we might have a new "Site" tab very soon when we start seeing signs of FSE in the editor. I think this is yet even more of a reason to stop clearing block selection. If at some point in the future we will require moving the selection in the document because we switched tabs, only then it is a good time to implement a mechanism for remembering previous selection states and applying them.

Implementing such a mechanism today will most likely require a refactor when block areas and whatnot shall appear.

The final thing is that the inspector is contextual and I also disagree with that, the inspector tabs are contextual not the entire inspector. Similar to this, desktop software only have contextual toolbars or sidebars, never changing things you can't see (such as the block tab in our case).

One example, props to @noisysocks , which behaves similar is Apple Pages where switching inspector tabs, even to document, does not clear any selection in the document:

[mapk]

As another example, Blocs.app seems to clear the selection when clicking another tab but returns the selection when the tab is clicked back again.

If the selection in Gutenberg didn't clear, what would happen if I have a block selected and clicked the Document tab? Would I just see the Document settings, but the block would still remain selected? Looking at the example from @noisysocks, it may not be a bad decision.

[draganescu]

Yes @mapk that's what I propose: when we click the Document tab we leave the current selected block be selected. That's all.

[jorgefilipecosta]

@jorgefilipecosta is there any technical reason to clear the block selection?

When we select a block, we switch to the block editor tab. I guess to have a block selected and show the document tab; we would need some changes on the logic of how selection and the tabs work. But I would not say it is something hard to change.

[draganescu]

@jorgefilipecosta shouldn't we simply not deselect the block anymore instead of making some more complication? Opening the block tab when we select a block is fine. Only deselecting the block when switching to the document tab should be removed.

@jasmussen or @mtias what do you still think about this? Should we let go of the current behaviour?

[jasmussen]

I appreciate the desire to improve things. But given this is an issue that has been argued to be working as intended by at least a couple of folks, it feels like a lot of energy has been spent on this instead of working on reported bugs or reviewing open PRs.

This tells me that this kind of issue is one that should just be tried, and kept if it works, reverted if it doesn't. But only if that can happen fast, it doesn't feel worth spending weeks on.

[jorgefilipecosta]

It appears there is no technical challenge, this behavior was implemented in #6936 because issue #6887 was opened.