[Proposal][Desktop] Let "ESC" key de-select currently selected item

[Seirdy]

Use case

Users expect de-selection to work like it does in other programs.

Selected items (including selected text, widgets, and tab-focused items) all require the mouse to de-select, which is inconvenient. Other desktop programs typically allow de-selecting items with the ESC key.

Proposal

Selected items should be de-selected when a user presses the ESC key. This includes:

• Selected text
• Selected (long-pressed) widgets: see screenshot below
• Tab-focused buttons

I had previously filed a ticket for Fluffychat and was directed to file it here.

I observed the lack of support for ESC deselection on the Linux desktop on Wayland, but I think it should be universal.

[HansMuller]

Interesting proposal. CC @gspencergoog

[justinmc]

@Seirdy Could you provide a code sample to reproduce this?

If the selection has caused the focus to change and we can receive the escape key, then I think this could be a straightforward fix by firing something like a DismissIntent.

[Seirdy]

On Fri, Feb 11, 2022 at 10:42:57AM -0800, Justin McCandless wrote: ***@***.*** Could you provide a code sample to reproduce this? I was simply referred to this bugtracker from the Fluffychat bugtracker; I'm not a Flutter dev. Maybe KrilleFear could share; I'll ping him in the Fluffychat Matrix room.

If the selection has caused the focus to change and we can receive the escape key, then I think this could be a straightforward fix by firing something like a DismissIntent.

I think that any sort of selection or focus, from tab-selection, text-selection, long-tap selection (IDK what the technical term is but that's what's in the screenshot), to being in a text box, should be cancelled with ESC. If I'm in a text box but I press ESC then tab, I shouldn't type a tab; I should change focus. If I'm using keyboard nav with tab-selection and arrow-key navigation, pressing ESC should cancel it. Otherwise, I have to use the mouse to quit keyboard navigation, which kind of defeats the point of keyboard navigation. Essentially this could be considered a meta-issue for grouping together all forms of deselection that ESC should handle.

[markusaksli-nc]

So aside from #98163 and #84416 what else is missing this? It would be helpful to aggregate places where this doesn't work as expected.

I'm slightly concerned about how far exactly this should go since not everything is consistent on desktop. Would it be fair to expect ESC to de-select selected text? Should it unfocus a focused text field if no text is selected? I'm not sure what the general case is for these but playing around with the browser and my IDE there are conflicting approaches. It's certainly doable by just going through a few checks in EditableTextState.

Also am I missing something or does pressing tab in EditableText just always navigate instead of entering anything?

[justinmc]

Currently tab always moves focus per these shortcuts in WidgetsApp. If you remove/override them, then a tab character will be inserted.

For escape behavior, I think ideally we should match the platform's behavior everywhere we can, with Chrome being the standard for web (I don't think I've seen a case of Flutter changing behavior per-browser). On something like Mac, if there seems to be no consensus for the behavior among apps, probably the standard would be to create a plain text field in a native Mac app in Xcode and see what it does by default.

That may be splitting hairs in some cases but I think that's what we should aim for.

[Seirdy]

This could also be considered an accessibility issue, as failing to de-select an item would violate all three levels of WCAG 2.2's Guideline 2.1 (Keyboard Accessible). One of Flutter's selling points is accessibility; this makes anything that disqualifies it from the WCAG's most lenient conformance level a big deal.

[flutter-triage-bot]

The triaged-desktop label is irrelevant if there is no team-desktop label or fyi-desktop label.