Multi-Selection: Pressing escape resets focus

[aduth]

Steps to reproduce:

1. Create new post
2. Insert a few blocks
3. Trigger multi-selection (shift-arrows, click-drag)
4. Press escape

Expected:

Focus (and block selection) moves back to selection start.

Actual:

Multi-selection is cleared, but focus is reset to the body.

[afercia]

Tested during today's accessibility bug-scrub and it still happens, though the focus loss is less evident now (because the More Options button gets focused and pressing Escape keeps focus in place in modern browsers). However, focus it still not moved back to the original insertion point or selected block.

[aduth]

It may be an open question as to whether Escape should trigger a deselection at all. If multi-selection is meant to behave similar to a native input uncollapsed selection (e.g. in this GitHub "Write" textarea), then Escape has no assigned behavior.

What do you think @afercia ?

[joedolson]

Tested with NVDA/Firefox 10/16 and this mostly works in the way described as 'expected' above, with focus moving back to selection start - except that you need to press escape twice before it takes effect. Without NVDA, it works with a single press of the key.

I'm not sure whether escape should trigger this behavior; I'm not aware of any other contexts where escape alone deselects text. I'm not sure it's a problem, since the escape key doesn't have another expected purpose in this context. In Word, you can deselect blocks of text using escape plus left-arrow, so this is similar.

Also in Word (and many other text editing contexts) you can deselect text by changing the cursor position. This isn't available from the keyboard when you have blocks selected, so having a keyboard accessible way to do this makes some sense.

[afercia]

Worth noting in Safari, pressing Escape produces the same JS TypeError: null is not an object (evaluating 't.nodeType') noticed also in #6165 / #10529

Selection is lost in Safari, thus the error. I'd guess the same happens in IE11. @aduth wouldn't be possible to consider to store the selection values somewhere and then use them?

Adding the "bug" label, as I guess Gutenberg shouldn't produce JS errors.

[aduth]

@aduth wouldn't be possible to consider to store the selection values somewhere and then use them?

Yeah, I think so. One of the changes included in #10529 is to shift from checking selection at time of focus-out to instead track it when focus is shifted.

https://github.com/WordPress/gutenberg/pull/10529/files#diff-5564a2a1451709de146c9763c35dbbaeR63

Adding the "bug" label, as I guess Gutenberg shouldn't produce JS errors.

Isn't the bug tracked by #6165 already, this one merely a casualty of it?

[afercia]

Thanks for clarifying. Sure, OK about the label.

[mrfoxtalbot]

I can confirm that this is still reproducible.

Screen.Capture.on.2022-07-26.at.17-01-47.mp4

[andrewserong]

I have an open PR in #48904 that tries dropping the user back to the block at the beginning of the selection when pressing Escape with multiple blocks selected in the editor canvas.

[andrewserong]

Resolved in #48904

Feel free to reopen if I've missed any nuances not covered by that PR, though!