Escape key should not close the editor

[PVince81]

Describe the bug
Don't close the editor unexpectedly when hitting escape.

To Reproduce
Steps to reproduce the behavior:

1. Type some text
2. Select a portion of the text
3. Hit escape to unselect the text
4. Be surprised, where did the editor go ?

Expected behavior
Editor stays open at all times when hitting Escape

Client details:

• OS: openSUSE Tumbleweed
• Browser: Firefox
• Version: 97.0
• Device: desktop

Server details:
c.nc.com

[juliusknorr]

@jancborchardt @nimishavijay What do you think about this one? I agree that initial escape should probably be catched during editing so that one could get the keyboard focus back to other ui elements, but not sure if we should then on the second escape not still close the viewer with text open.

[PVince81]

does the escape key also close Collabora ?

for a viewer I think escape key closing is fine but not something you can work actively in

[mejo-]

I think that Text in Viewer is a bit different than a picture, video or PDF. If I open a file for editing, I wouldn't expect the editor to disappear when hitting Esc. Even not when hit a second time. That's why I would suggest to catch Esc in general and don't let it close the viewer.

[nimishavijay]

I think it's important for keyboard accessibility to have an easy way to close the editor using the keyboard. If nothing is selected/highlighted/no popovers or menus are open then I'd say it would be okay to close the editor. Since it feels like something "opened" like a modal, using Esc key to close it makes sense.
First Esc key could close any action menu or popover/unselect text and clicking the Esc key twice could close the editor.

[jancborchardt]

First Esc key could close any action menu or popover/unselect text and clicking the Esc key twice could close the editor.

Fully agree on that.

Also tested with some other things:

• Gmail doesn’t do any 2-step thing, Esc directly closes the composer and saves the draft
• Notion "new page" does it similar to Gmail when you are in the title, but has a weird 2-step when in the content, selecting the "container"/"module" of the text
• Any textarea or input field in the browser unselects on Esc, so yes it is behavior we should respect (LibreOffice unselects on Esc as well, for the record)

[mmuman]

It is especially painful when you use a ":" with a space before (as per French typography rules) and you get proposed emojis and you don't want them, you end up exiting the edition instead of getting out of the emoji selector.

[juliusknorr]

Might also be an accessibility feature if we let esc bring the focus back to the page outside the editor field.

[susnux]

This is especially annoying as there is (as far as I know) no shortcut to close the formatting help popover except ESC, but that closes not only the formatting help but also the whole editor

[mejo-]

So we have at least four cases where Esc should not close the editor but instead do something else:

• When the emoji autocompletion list is open, Esc should close the list, not the editor
• When the user mention autocompletion list is open, Esc should close the list, not the editor
• When the formatting help modal is open, Esc should close this very modal, not the editor
• When text is selected, Esc should unselect the text

[nimishavijay]

I would also add that whenever any of the formatting options have menus (eg emojis, callouts etc) which are open, the esc key can first close that before closing the editor, right now if you are using your keyboard to open the callout menu, it stays open even if you navigate away to a different formatting option.
@mejo- @jancborchardt