1745009 - Reconsider response to "Esc" in composition editor and tidy up

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Henry Wilkes (they/them) [:henry-x]]

Currently, if you press "Esc" whilst focussed in the editor it will try and close the "Find in page" bar if it is visible, otherwise it will try and close the most recent notification (which is lowest on the screen).

There also seems to have been some idea to have the same behaviour in the subject input (https://searchfox.org/comm-central/rev/78e32fedfc633819cf272be3f8254c2877ea69eb/mail/components/compose/content/MsgComposeCommands.js#2857) but this is broken.

If you are focussed in the find bar, pressing "Esc" will close it.

If you are focussed in a notification, pressing "Esc" will close it if and only if it is the most recent notification. This needs fixing.

With bug 1729314 and bug 1729714 fixed, the "Find" bar and the notification elements are easier to access with the keyboard from the editor (provided the user knows about "F6" or "Ctrl+Tab"), so I wonder if we could drop the "Esc" behaviour in the editor.

In any case, the section of code needs a quick tidying up, so I'll do that first.

Once we're decided on the behaviour, we should probably add a test as well.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1745009 - Clean up handling of "Escape" in compose window. r=aleca

Got rid of dead code, and ensured notifications can be closed with "Escape" even when they are not the most recent.

Depends on D133194

Comment 2

[Thomas D. (:thomas8)]

(In reply to Henry Wilkes [:henry] from comment #0)

With bug 1729314 and bug 1729714 fixed, the "Find" bar and the notification elements are easier to access with the keyboard from the editor (provided the user knows about "F6" or "Ctrl+Tab"), so I wonder if we could drop the "Esc" behaviour in the editor.

Knowing about "F6" is non-trivial, and would still force users into unnecessary steps even if they know. Being able to press "Esc" in the editor to remove any unwanted bars which are still hanging around looks like a convenience feature, and I see no reason to remove that convenience.
It's especially convenient when automagical attachment reminder bar pops up whilst you're writing keywords like "attachment". If it was a false positive and you want to get rid of the bar, you can just press ESC right there where you are, without hassles of having to focus the bar first before closing it.

Comment 3

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Thomas D. (:thomas8) from comment #2)

Knowing about "F6" is non-trivial, and would still force users into unnecessary steps even if they know. Being able to press "Esc" in the editor to remove any unwanted bars which are still hanging around looks like a convenience feature, and I see no reason to remove that convenience.

Its not clear to me how a user would know about the editor "Esc" behaviour. I think the "Find" bar can be seen as part of the same composite widget, but the notification bar seems like a separate widget (the attachment area is between them, also see below) so it's not obvious that pressing just "Esc" in the focussed editor would perform some action there.

It's especially convenient when automagical attachment reminder bar pops up whilst you're writing keywords like "attachment". If it was a false positive and you want to get rid of the bar, you can just press ESC right there where you are, without hassles of having to focus the bar first before closing it.

I think the difference now is that there are more ways to get notifications that aren't triggered by the editor. As such, the notification bar has become more distinct from the editor. It's not clear that pressing "Esc" in the editor should close a notification about too many public recipients. Maybe that's part of the problem: that the notification bar is shared by several widgets, when it might make more sense for them to pop up locally.

My impression is that this only existed for the attachment notification because it could pop up often. Personally, I feel like the attachment notification is too keen and distracting, when we could just warn the user when they actually press "Send".

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

We should also bear in mind that "Esc" is already used for several other things in the compose window, but each of these only effect the focussed widget:

• Closing the application header menus (File, Edit, etc).
• Closing the identities menu.
• Closing the extra recipients menu.
• Cancelling editing a pill.
• Cancelling an address book auto-complete.
• Closing a context menu (including in the editor).
• Deselecting an attachment item.

Also, there is another "Esc" behaviour that doesn't quite fit in this, and probably should be reviewed as part of this bug:

• When focussed in the attachment bucket (not the attachment expander) and no attachment item is selected, move the focus from the attachment area to the editor body.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d33fd6578f8e
Clean up handling of "Escape" in compose window. r=aleca

Comment 6

[Thomas D. (:thomas8)]

Detailed analysis, Henry! I also like your approach of improving the code.

Please restore Esc behaviour from subject to close notifications. This is when user types attachment keyword in subject, it's a false positive, and pressing Esc will immediately dismiss the unwanted and hence irritating notification. That's quite convenient, it was there for a reason, and keeping it won't hurt afasics.

It would actually be great if we can extend that behaviour so that when public bulk notification appears whilst typing recipients, user can also press ESC on an (empty) address input to hide that notification immediately.

(In reply to Henry Wilkes [:henry] from comment #4)

We should also bear in mind that "Esc" is already used for several other things in the compose window, but each of these only effect the focussed widget:
...
Also, there is another "Esc" behaviour that doesn't quite fit in this, and probably should be reviewed as part of this bug:

• When focussed in the attachment bucket (not the attachment expander) and no attachment item is selected, move the focus from the attachment area to the editor body.

The common denominator for all the uses including the latter is "Escape" from, i.e. close / get me out of the focused widget. Pretty much the same for attachment pane.

Please do not remove the ESC keyboard shortcut to move focus from attachment pane back to body, because this shortcut...:

• is extremely convenient (much easier to remember than moving focus backwards with Shift+Tab or Shift+F6): Just hit double-ESC after adding attachments, and you're back to body. (*)
• is required for accessibility, as we have blind people on record who love and depend on this shortcut.
• is much easier to figure out than F6 (while making ESC more discoverable would be welcome)
• doesn't interfere with any other expected uses of ESC, so it doesn't hurt.
• is extremely low cost in code, and doesn't come with a performance penalty

(*): We've had discussions on other bugs because different users have different needs: After adding attachments, some users want focus on attachment (which enables lots of subsequent actions on the attachment, including attachment verification for the blind), and others would want it back in body automatically. Magnus doesn't like prefs, so double-ESC simplifies the workflow for the latter group.

Comment 7

[Thomas D. (:thomas8)]

For the avoidance of doubt, remote-closing notifications with ESC is a highly convenient no-brainer behaviour, unmatched in simplicity by any other keyboard alternatives.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Henry Wilkes [:henry] from comment #3)

I think the difference now is that there are more ways to get notifications that aren't triggered by the editor. As such, the notification bar has become more distinct from the editor. It's not clear that pressing "Esc" in the editor should close a notification about too many public recipients. Maybe that's part of the problem: that the notification bar is shared by several widgets, when it might make more sense for them to pop up locally.

Good point. We could explore if the public-bulk-recipients notification (and similar recipient-related notifications) could pop up directly below the addressing widget, and then allow ESC from (empty) address input to close such notifications immediately when they pop up, hassle-free. However, note that we're using full-window-width for notifications at the bottom, which is not available below addressing widget when contacts side bar is open, so esp. for low-width-windows, notification might get squeezed.

My impression is that this only existed for the attachment notification because it could pop up often. Personally, I feel like the attachment notification is too keen and distracting, when we could just warn the user when they actually press "Send".

Well, not really...

• We actually want to notify the user early, not in the last second. We are triggering on keywords, so delaying the notification until send time would also lose the logical connection between typing the keyword and getting the notification, which is crucial for understanding the behaviour.
• This is a great unique feature which makes TB better than other clients in this respect.
• You can Disable attachment reminder for the current message from the dropdown of Remind me later | v button on the notification.
• If you don't like being notified at all, you can uncheck Check for missing attachments in settings, and I think there's a hidden aggressive pref again.
• If you don't like the keywords, you can just change them (Click on underlined keyword in notification, or Keywords button in prefs, next to the Check... pref).

That said, keywords and keyword handling could be better, and should probably have some localized adaptations. We have some bugs for that on record.

Comment 9

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Thomas D. (:thomas8) from comment #6)

Please restore Esc behaviour from subject to close notifications. This is when user types attachment keyword in subject, it's a false positive, and pressing Esc will immediately dismiss the unwanted and hence irritating notification. That's quite convenient, it was there for a reason, and keeping it won't hurt afasics.

I'm not sure. Pressing Esc in the subject line to close a separate widget is obscure. I'm not sure how a user would think to do that unless they looked through the code.

The common denominator for all the uses including the latter is "Escape" from, i.e. close / get me out of the focused widget.

Esc usually means "close" or "cancel", but I'm not sure just moving focus makes sense other than a necessary secondary effect of closing or cancelling a selection. Have you got an example of Esc being used elsewhere for the second effect?

Please do not remove the ESC keyboard shortcut to move focus from attachment pane back to body, because this shortcut...:

• is extremely convenient (much easier to remember than moving focus backwards with Shift+Tab or Shift+F6): Just hit double-ESC after adding attachments, and you're back to body. (*)

What I'm unsure of is how a user would intuit this behaviour. Why would they think to press Esc twice? I feel like Shift+Tab is most likely, and is supported. Moreover, the F6 or Ctrl-Tab behaviour is documented (https://support.mozilla.org/en-US/kb/keyboard-shortcuts) so is more likely to be found by a user searching than Esc (which only works in the special case of focus being in the attachment bucket with no selection).

My problem with the use of Esc is:

1. It effects non-focused widgets. E.g. closing notifications from the editor (or subject line).
2. It has too many specific and conditional behaviours that a user can't be expected to know about. E.g. it will close notifications from the editor, provided the find bar is not open, but not elsewhere. It will move focus from the attachment bucket to the editor, provided an attachment is not selected, but it won't move focus from the attachment expander or the language button to the editor.