Improve moving focus back from the toolbars to the blocks, see focusSelection()

[afercia]

Noticed while testing the "navigation/edit mode" PR #5709.

The formatting toolbar implements a keyboard-friendly feature: when focus is on the toolbar and the Escape key is pressed, focus is moved back to the selection (or insertion point) in the editable text of the block. See in editor/components/navigable-toolbar/index.js the focusSelection() function.

This works pretty well for editable blocks and focus is moved back to the previous selection or caret position.

However, I'd like to propose a few improvements:

1
with the "navigation/edit mode" in #5709 , pressing Escape moves focus back to the selection and then immediately switches back to "Navigation mode" so focus is moved back to the block wrapper.
Seems to me that just stopping the event propagation would fix this.

2
In the inline toolbars (e.g. the ones for the captions):

pressing Escape from the inline toolbar does nothing. Also in this case, focus should be moved back to the selection/insertion point in the editable field. I guess focusSelection() should be abstracted a bit and used also for the inline toolbars.

3
Not all blocks have editable fields that can get a selection. For example, consider this scenario:

• working on a paragraph, the selection or insertion point gets stored
• then move to a block that doesn't have selectable fields, e.g. an image block before setting the image
• focus the image block toolbar and press Escape
• focus is moved back to the previous block selection: the paragraph
• expected: focus should move back to the image block wrapper

In this case, I guess a possible solution would be:

• check if the current selection pertains to the selected block
• if not, return early focusSelection() to allow "navigation/edit mode" to move focus back to the block wrapper

/cc @youknowriad any feedback and thoughts welcome

[youknowriad]

The last point might be tricker to achieve but yeah, these all make sense to me 👍

[mtias]

Should we consolidate with #3003 ?

[afercia]

2 and 3 are still a problem on current master 3.8.0-rc.1 and need to be fixed. 1) actually depends if navigation / edit mode will be implemented, not a great progress there lately and needs to be reconsidered.

[tofumatt]

I'm moving this from the merge milestone and into the 5.0 milestone because while I agree it'd be nice to have these improvements, I don't think they're critical. 😄

[afercia]

Summarizing the state of the 3 points above:

1. not so relevant as "navigation/edit mode" in Accessibility: Try adding the keyboard navigation/edit mode #5709 is stale at the moment
2. to my understanding, it should be covered by Editor: Add KeybindScope complement to NavigableToolbar #10699 /Cc @aduth
3. still a problem and needs to be addressed, as focus is moved back to the wrong block

[paaljoachim]

@joedolson Joe. Perhaps you could take a look at add an update to this issue?
Thank you!

[glendaviesnz]

Point 3. seems to be resolved in 5.8 and Gutenberg 11.3, ie. hitting esc on an Image toolbar item returns focus to the Image block toolbar rather than the previously selected paragraph block:

[jeryj]

Testing this out today in the Accessibility Bug Scrub and looks like we have a regression. Pressing escape from the block toolbar loses focus to the top of the editor canvas iframe. I'd expect pressing escape from the block toolbar returns me to the previous focus on the block.

[Mamaduka]

@jeryj, that sounds very similar to this issue #45767.

[jeryj]

@Mamaduka - yes, I think they're the same issue. I'll close and we can follow up on #45767.