Closed Bug 1667614 Opened 4 years ago Closed 4 years ago

Implement Shift+Home keyboard shortcut from address input for selecting all pills of the address row.

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement

Tracking

(thunderbird_esr78+ fixed, thunderbird82 fixed)

RESOLVED FIXED
83 Branch
Tracking Status
thunderbird_esr78 + fixed
thunderbird82 --- fixed

People

(Reporter: thomas8, Assigned: thomas8)

References

(Blocks 1 open bug)

Details

(Keywords: ux-consistency, ux-efficiency)

Attachments

(1 file, 1 obsolete file)

With cursor in first position of an empty or whitespace-only address input, Shift+Home should select all pills contained in the address row. I keep trying this keyboard shortcut all the time, and it's so boring when it doesn't work. Time to implement it! :-)

Is this a commonly used keyboard shortcut?
We already have the CTRL+A implemented that does the same exact thing when pressed twice (or does not?).
I don't think we should implement and support multiple shortcuts that do the same exact thing as it adds to the burden of maintaining.

On a related note, we should start implementing tests to cover all the accessibility feature we currently have for the pills. That's a more impending priority IMHO.

Implement Shift+HOME from address input to select all pills within the addressing row. Shift+Ctrl+HOME will work, too.
Deliberately not yet handling Shift+HOME starting out from a pill, that's for another day.

While we are here, nitfix a hard-coded ID reference to the addressing area and nitfix that Alt+Backspace from address input should not delete pills.

Attachment #9178054 - Flags: review?(alessandro)

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

Is this a commonly used keyboard shortcut?

Yes. Plain vanilla standard keyboard shortcut both for text and items, and pills have both notions.

We already have the CTRL+A implemented that does the same exact thing when pressed twice (or does not?).
I don't think we should implement and support multiple shortcuts that do the same exact thing as it adds to the burden of maintaining.

??? Come on... Convenience and ux-efficiency matters, we don't want to fail users' muscle memory for nothing. We offer several ways of killing the cat all over in Thunderbird, that's how we serve different users with different needs. No maintenance burden. 2 lines of code which will just continue to sit where we put them now. If anyone is going to touch that, it's most likely me: For the same reasons, we also want Shift+Pos1 starting out from any pill (where Ctrl+A won't do the trick).

On a related note, we should start implementing tests to cover all the accessibility feature we currently have for the pills. That's a more impending priority IMHO.

I agree that tests are great, but stuff that just works as users can expect it from widely known standards since time immemorial is even greater.

Status: NEW → ASSIGNED

Btw, @aleca, pls remember your comment on meta bug 1602397, where you actually asked me to implement Shift+HOME, only that you accidentally mistyped that as Shift+END.

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

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 HOME key should select all pills between a previously focused pill and the first available pill.

Thomas, would you be able to handle this?

Of course whereever I said POS1 (Position1, the German key label for HOME), I really mean HOME (I've fixed that in my comments).

https://defkey.com/what-means/shift-home lists 49 programs using this shortcut, and they forgot Windows Explorer and probably more, because all navigation keys, if combined with SHIFT, work for continuous text/item selection, everywhere.

Fyi, https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts seems to have a pretty comprehensive cross-OS overview (found just now, haven't checked for quality yet).

They list HOME/END for "Select/move to first/last item in selected widget", whereby selection always requires Shift modifier, so that entry happens to be inaccurate and incomplete in their table.

Summary: Implement Shift+Home keyboard shortcut for selecting all pills from address input → Implement Shift+Home keyboard shortcut from address input for selecting all pills of the address row.

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

We already have the CTRL+A implemented that does the same exact thing when pressed twice (or does not?).

Shift+Home: Select all pills from focus point (cursor in address input OR a focused pill) to the beginning (which might be all pills, or less).
Ctrl+A: Select all pills of focused address row.
Ctrl+A, Ctrl+A: Select all pills of all addressing rows (i.e. all pills of the entire addressing area).

Thanks for the details and analysis of the implementation.
I don't know why but my initial understanding was that you wanted to implement this for those extra headers that don't use the pills, my bad.
This makes sense.

Comment on attachment 9178054 [details] [diff] [review] 1667614_addressInputShiftPos1.diff Review of attachment 9178054 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for taking care of this. Let's update the commit message with Shift+Home instead of Shift+Pos1. A little comment nit in the code, and I'm gonna ping Magnus for a tiny coding style feedback. ::: mail/base/content/mailWidgets.js @@ +2754,5 @@ > if (sourcePill) { > sourcePill.setAttribute("selected", "selected"); > } > + if (event.key == "Home" && !sourcePill) { > + // Shift+Home from address input nit: period at the end. ::: mail/components/compose/content/addressingWidgetOverlay.js @@ +604,5 @@ > event.preventDefault(); > > let previous = input.previousElementSibling; > if (previous && previous.tagName == "mail-address-pill") { > + input.closest("mail-recipients-area").selectPills(previous); I always knew that getElementById() was usually faster than any other selector, and since we're using that ID only here I'm not sure changing this brings any benefit other than styling. Let's ask Magnus since he has a better overview of the code styling we should aim for.
Attachment #9178054 - Flags: review?(alessandro)
Attachment #9178054 - Flags: review+
Attachment #9178054 - Flags: feedback?(mkmelin+mozilla)
Comment on attachment 9178054 [details] [diff] [review] 1667614_addressInputShiftPos1.diff Review of attachment 9178054 [details] [diff] [review]: ----------------------------------------------------------------- Let me explain the motivation of removing an absolute ID from what is essentially the inner code of the <mail-recipient-area> custom element... ``` ::: mail/components/compose/content/addressingWidgetOverlay.js @@ +604,5 @@ > event.preventDefault(); > > let previous = input.previousElementSibling; > if (previous && previous.tagName == "mail-address-pill") { > + input.closest("mail-recipients-area").selectPills(previous); ``` My change isn't motivated by micro-performance, it's motivated by avoiding hard-coded IDs and having self-contained functionality in the <mail-recipient-area> custom element. Please note: * addressingWidgetOverlay.js should probably not even exist any more. The corresponding addressingWidgetOverlay.xul is gone, and it's just totally confusing to have addressing area code scattered all over the place. Alex and I certainly know... * addressInputOnBeforeHandleKeyDown() and other handlers are inherently part of the <mail-recipients-area> implementation, so they should live in mailWidgets.js, just like the rest of the functionality which is already there. * The code of the <mail-recipients-area> custom element should be self-contained and using relative references to its own sub-elements. Which ID the <mail-recipient-area> happens to have in our main composition document should not matter for the internal workings of the custom element. Iow, code inside the element should never depend on the outside ID of the element which it cannot control. * So this is all about having self-contained inner code for the functionality of a custom element which won't break or need unnecessary code adjustments just because someone decides that the ID in the layout document should change. That's a matter of code styling principles indeed. * Iirc, Magnus actually recommended avoiding hard-coded references when we were initially working on the pills implementation.
Comment on attachment 9178054 [details] [diff] [review] 1667614_addressInputShiftPos1.diff Review of attachment 9178054 [details] [diff] [review]: ----------------------------------------------------------------- Yep, getElementById is faster, but I don't think it matters here and it's more clear and self confined to do as proposed
Attachment #9178054 - Flags: feedback?(mkmelin+mozilla) → feedback+

Add a dot in comment.

Attachment #9178054 - Attachment is obsolete: true
Attachment #9178758 - Flags: review+

We should also land this on TB78, to polish the addressing area transition experience from TB 68.
In TB 68, it was possible to type multiple comma-separated addresses into a single input and select them with Shift+Home (only before pressing Enter).

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/c5e1348f8afb
Implement Shift+Home keyboard shortcut for address inputs to select all pills. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Comment on attachment 9178758 [details] [diff] [review]
1667614_addressInputShiftPos1.diff

Pills polish

Attachment #9178758 - Flags: approval-comm-esr78?
Attachment #9178758 - Flags: approval-comm-beta?

Comment on attachment 9178758 [details] [diff] [review]
1667614_addressInputShiftPos1.diff

[Triage Comment]
Approved for beta

Attachment #9178758 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9178758 [details] [diff] [review]
1667614_addressInputShiftPos1.diff

[Triage Comment]
Approved for esr78

Attachment #9178758 - Flags: approval-comm-esr78? → approval-comm-esr78+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: