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 2. 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. 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. 4. Tab-navigating into a recipient field (even after bug 1602372) 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). 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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
Bug 1602397 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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 2. 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. 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. Tab-navigating into a recipient field (even after bug 1602372) 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). 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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 2. 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. 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. Tab-navigating into a recipient field (even after bug 1602372) 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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 2. 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. [should be fixed by bug 1602431] 3. 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. [should be fixed by bug 1602431] 4. Tab-navigating into a recipient field (even after bug 1602372) 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. [related: bug 1602372] 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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 2. 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. [should be fixed by bug 1602431] 3. 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. [should be fixed by bug 1602431] 4. Tab-navigating into a recipient field (even after bug 1602372) 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. [related: bug 1602372] 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. Ctrl+clicking on a selected recipient pill must not lose focus, but ensure focus on that pill. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 2. [Fixed by 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 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. [ongoing work in bug 1602372] Tab-navigating into a recipient field (even after bug 1602372) 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. Ctrl+clicking on a selected recipient pill must not lose focus, but ensure focus on that pill. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 2. [Fixed by 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 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. [ongoing work 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. Ctrl+clicking on a selected recipient pill must not lose focus, but ensure focus on that pill. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 2. [Fixed by 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 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. [ongoing work 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. 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 2. [Fixed by 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 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 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. 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 2. [Fixed by 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 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 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 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. Bug 1637657 - Selection of recipient pills with modifier keys (Shift+▶, Ctrl+▶) unexpectedly lost when reaching row input Filed patch attachment 9148062 [details] [diff] [review]. 9. [Fixed by me in Bug 1615917] Allow incremental selection of recipient pills with Ctrl+A *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 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. Bug 1637657 - Selection of recipient pills with modifier keys (Shift+▶, Ctrl+▶) unexpectedly lost when reaching row input Filed patch attachment 9148062 [details] [diff] [review]. 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). *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 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). *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 cursor in rowInput (Shift+click-pill, Shift+End, Shift+Home) 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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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. *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 - 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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 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 *: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=674bb73bd2b093deb8170dc8ecd7d67b5d1239a9
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