1602397 - [META] Rectify and improve recipient pills selection methods (mouse, keyboard). Shift+End/Home, Shift+click, focus vs. select...

Status: NEW

(Thunderbird :: Message Compose Window, enhancement, P3)

Description

[Thomas D. (:thomas8)]

As a rule of thumb, we want to mimick Windows Explorer item selection procedures and behaviour, they've done a pretty good job which represents the de-facto standard.

I am looking at the latest available iteration of bug 440377 (try build 73.0a1 (2019-12-06) (64-bit).*

Issues and improvements when selecting pills (e.g. for copy/cut/delete):

1. With any pill selected (e.g. pill-1), hold Shift and...

• ... click another pill-n: should select all pills between pill-1 and pill-n, but doesn't.
• ... press END key: should select all pills between pill-1 and last pill, but doesn't.
• ... same by analogy for HOME key
• same by analogy starting from caret cursor in empty rowInput:
  • Shift+click-pill
  • Shift+Home [Fixed by me in Bug 1667614]

2. [Fixed by me in bug 1602431] After entering recipients, cursor is after the last recipient (ok). Unmodified cursor left (going back) focuses, but does not select the last recipient. It should.

3. [Fixed by me in bug 1602431] Unmodified cursor navigation of recipients must always focus and select each recipient (except with Ctrl modifier: move focus ring only). (Same for End/Home keys, and Page Up/Down; see 5 below). Cf. Win Explorer behaviour: any plain movement key selects the navigation target. Not selecting makes it a pita to act on single focused items, e.g. you can't cut/copy using Ctrl+X/Ctrl+C.

4. [Fixed by Alex in bug 1602372] Tab-navigating into a recipient field focuses the first recipient without selecting. That's correct and consistent (cf. Win Explorer). Probably to prevent unintended selection and potential errors resulting from that (e.g. pressing DEL thinking that your focus is in body). Selecting a focused pill is as easy as pressing space bar (ok). - Alternatively, we could focus the field and offer a text cursor after the last pill, if we believe that adding another recipient is the most likely action.

5. Please implement Cursor up/down and Page up/down for plain and Ctrl/Shift-modified navigation. Same behaviour by analogy as for cursor keys. Cf. Win Explorer.

6. [Fixed by me in bug 1633555] Ctrl+clicking on a selected recipient pill must not lose focus, but ensure focus on that pill.

7. Shift+navigation key and Shift+click on another pill from focused, but unselected pill must also select the focus pill

EDIT 2020-05-13:

8. [Fixed by me in Bug 1637657] Selection of recipient pills with modifier keys (Shift+▶, Ctrl+▶) unexpectedly lost when reaching row input.

9. [Fixed by me in Bug 1615917] Allow incremental selection of recipient pills with Ctrl+A

EDIT 2020-06-19:

10. Ctrl+right-click on an unselected recipient pill must NOT select it. Ctrl is "preserve existing selection for next click". Selecting generally requires left-click. Adding to selection requires Ctrl+left-click, right-click is for context menu. As an exception, only unmodified right-click on a single unselected pill will select it as a courtesy. This is the de-facto standard behaviour since time immemorial on Windows (cf. Windows Explorer selection patterns). Whilst this might be an arguable edge case, it would be unexpected and error-prone for Thunderbird to deviate from such established selection patterns. It's also important that Ctrl+right-click must not select because it's a way of getting at the whitespace context menu by ctrl+right-clicking on items if there's no selection (sic).

EDIT 2021-03-17:

11. Shift+navigation keys on a one-block selection must also allow deselection in reverse direction. E.g. Shift+cursor-left: select pills 5 to 2, then Shift+cursor right must deselect starting from pill 2, then pill3, etc.

EDIT 2022-03-15:

12. Make Select all (pills) available for mouse users via (context) menus (via keyboard, it's Ctrl+A for current field, or Ctrl+A, Ctrl+A for all fields).

• With focus on a pill:
  [Fixed by me in Bug 1760692] Implement Select all addresses in {To|Cc|Bcc etc.} and Select all addresses from pill context menu (mouse equivalent of [2x] Ctrl+A)
• With focus in recipient input when there's no text of an unfinished address:
  Bug 1686949 - Enable "Select all" in context menu of empty address input (To/CC/BCC) to select all pills with mouse (Ctrl+A mouse equivalent)

*: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9

Comment 1

[Alessandro Castellani [:aleca]]

It seems we took care of almost all the various quirks.

It'd be nice to focus on the SHIFT implementation here with the following:

• Shift + Click on a pill will focus all the pills between a previously focused pill and the currently clicked pill.
• Shift + END key should select all pills between a previously focused pill and the last available pill.
• Shift + END key should select all pills between a previously focused pill and the first available pill.

Thomas, would you be able to handle this?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #1)

It seems we took care of almost all the various quirks.

Hmm, really? At the time of that comment, 4 out of 7 tasks (1, 5, 6, 7) from comment 0 were still outstanding, some of them with several sub-tasks. And there's more which isn't even on the list yet...

It'd be nice to focus on the SHIFT implementation here with the following:

• Shift + Click on a pill will focus all the pills between a previously focused pill and the currently clicked pill.
• Shift + END key should select all pills between a previously focused pill and the last available pill.
• Shift + END key should select all pills between a previously focused pill and the first available pill.

So that looks like tasks 1 and 7 from comment 0, covering the most basic cases of a single, contiguous block selection. Unfortunately for feature-completeness, we also need to cover noncontiguous selections involving Ctrl, e.g. cases where user selects random non-adjacent pills in random order, focus is on a satellite pill which isn't selected, and user can add to selection using Ctrl+Shift+Space. In some of such cases it's no longer the focused pill, but the last selected pill which matters (cf. Windows item selection behaviour as seen in Explorer). So it's less trivial than it looks.

Thomas, would you be able to handle this?

I'd think so, yes, and will certainly need your input, too. It's a lot of intricate work, which needs real professional working hours to cover all scenarios, so I'll look into this in due course when or if such working hours will be available on my side.

In the meantime, I'll offer a patch which fixes Shift+Cursor-right selections involving the last pill, which can be used as a bandaid substitute for Shift+End.

Comment 3

[Thomas D. (:thomas8)]

Following Alex' comment 1, I have fixed bug 1633555, which is task 6 of comment 0:
Loss of focus after unselecting a selected recipient pill with Ctrl+Click blocks keyboard access to pills

Comment 4

[Thomas D. (:thomas8)]

So this bug has de facto turned into a meta bug about recipient pill selection issues, as work gets done in blocking bugs listed in "depends on".
Let's make that official, and continue that way - any fixes to go into their own dedicated bugs.

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

In the meantime, I'll offer a patch which fixes Shift+Cursor-right selections involving the last pill, which can be used as a bandaid substitute for Shift+End.

Comment 0, adding task 8:
Bug 1637657 - Selection of recipient pills with modifier keys (Shift+▶, Ctrl+▶) unexpectedly lost when reaching row input
Filed patch attachment 9148062 [details] [diff] [review].

Comment 5

[Thomas D. (:thomas8)]

Mass-changing bugs around the new recipient area (pills) from product/component MailNews Core/Composition to Thunderbird/Message Compose Window, because composition frontend code is not shared with SM. Mostly cloned from Bug 440377 which started out in MailNews Core long back.

20200614002RecipientPillsProductChangeTypeEnhancement

Comment 6

[Thomas D. (:thomas8)]

Added task 10:

(In reply to Thomas D. from comment #0)

10. Ctrl+right-click on an unselected recipient pill must NOT select it. Ctrl is "preserve existing selection for next click". Selecting generally requires left-click. Adding to selection requires Ctrl+left-click, right-click is for context menu. As an exception, only unmodified right-click on a single unselected pill will select it as a courtesy. This is the de-facto standard behaviour since time immemorial on Windows (cf. Windows Explorer selection patterns). Whilst this might be an arguable edge case, it would be unexpected and error-prone for Thunderbird to deviate from such established selection patterns. It's also important that Ctrl+right-click must not select because it's a way of getting at the whitespace context menu by ctrl+right-clicking on items if there's no selection (sic).

Comment 8

[Thomas D. (:thomas8)]

Added task 11 to comment 0:

11. Shift+navigation keys on a one-block selection must also allow deselection in reverse direction. E.g. Shift+cursor-left: select pills 5 to 2, then Shift+cursor right must deselect starting from pill 2, then pill3, etc.

Comment 10

[Thomas D. (:thomas8)]

Added task 12 to comment 0:

12. Make Select all (pills) available for mouse users via (context) menus (via keyboard, it's Ctrl+A for current field, or Ctrl+A, Ctrl+A for all fields).

• With focus in recipient input when there's no text of an unfinished address:
  Bug 1686949 - Enable "Select all" in context menu of empty address input (To/CC/BCC) to select all pills with mouse (Ctrl+A mouse equivalent)
• With focus on a pill