+++ This bug was initially created as a clone of Bug #1666847 +++

Proposal (for exploration of feasibility):

Implement the following keyboard shortcuts for easy and efficient cross-localization keyboard access to the three main addressing fields in the composition window:

Ctrl/Cmd+Shift+T --> To
Ctrl/Cmd+Shift+C --> Cc
Ctrl/Cmd+Shift+B --> Bcc

Motivation:

• Several users have asked for easier ways of disclosing CC and BCC fields, and also the idea of having dedicated keyboard shortcuts for To, CC and BCC has repeatedly come up.

• To, CC, and BCC are extremely important address fields, likely to be used dozens of times every day by a large number of users, especially in enterprise contexts.

• Moreover, in the process of composing an email, users might want to go back to the addressing fields to edit/add/remove recipients.

• Such everyday high-frequency actions should be as efficiently accessible as possible.

• It speaks volumes that even gmail as a webmailer has deemed it necessary to have dedicated keyboard shortcuts just for disclosing and focusing the three main types of addressing fields.

• Using the same keyboard shortcuts like gmail will ease the transition for users of gmail webmail into Thunderbird. No need to reinvent the wheel.

• Also, as real keyboard shortcuts (as opposed to access keys) these will be non-localized in Thunderbird, which is an advantage for users, support and developer maintenance alike.

Implementation

• Technical implementation should be a non-brainer, as these shortcuts should work from anywhere in the compose window, so probably just <keys>.
• Making the key combinations available as unique keyboard shortcuts is less trivial, also with a view on future uses. I think it's worth trying, and even reshuffling a bit to make these premium shortcuts work.

Exploring feasibility: Current and future shortcut conflicts and ways out

• Ctrl+Shift+T is currently available in composition context. However, in the distant future when composition might live in a tab, it will conflict with Ctrl+Shift+T for "Undo close tab". "Undo close tab" is magnitudes less frequent and important for TB than efficient acccess to To-field. We could try to think of something now, or postpone that issue to when it really arises.
• Ctrl+Shift+C is currently available in composition context. However, in the distant future when composition might live in a tab, it will conflict with Ctrl+Shift+C for "Calendar tab". Calendar is very important, probably more important than efficient access to CC field.
  Unfortunately that would also rob us of an intuitive shortcut for "Copy formatting", a long-requested feature for the compose editor. We could try to think of something now, or postpone that issue to when it really arises.
• Ctrl+Shift+B is currently used for "Address Book" both in composition and 3-pane contexts. That's important, but I suspect far less frequently used than efficient access to Bcc field. We could try to find another shortcut for "Address Book", but the most intuitive alternatives like Ctrl+Shift+A are also taken in both contexts. Shuffling shortcuts is an art.

Another way out: The shortcut panel approach

Trying to think out of the box, Alex' plans for a location toolbar in Thunderbird springs to mind. If we had a single entry point access/shortcut key for focusing that (or some sort of master shortcut panel in the middle of the screen), things like Calendar and Address book could subsequently be covered with single letter (on-screen) shortcuts from that toolbar/pane context, which could free up their current shortcuts. Reversely, we could also try the same for the shortcuts proposed here, to have a central access panel on one shortcut, and then one-letter shortcuts to pick one from the panel context.

Aleca, any comments/insights/ideas?

This covers a high-relevance subset of your Bug 1683223 - Implement keyboard shortcuts offering quick access to primary addressing fields.

Indeed, this comes from the same motivation behind Bug 1683223.
In that bug I suggested to use the combination of CTRL + ALT instead of SHIFT to prevent possible conflicts with other keys.

Magnus doesn't consider this to be trivial, but I think we should definitely implement shortcuts to give quick access to important areas of every section, without exclusively relying on the TAB focus, which works in a list context but is not an optimal solution when outside a linear interaction pattern.

Do you want me to mark my bug as duplicate of this and continue the conversation here, and cover all the other fields?

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

Indeed, this comes from the same motivation behind Bug 1683223.
In that bug I suggested to use the combination of CTRL + ALT instead of SHIFT to prevent possible conflicts with other keys.

I've commented there why I don't think that's feasible (Bug 1683223 Comment 2).

Magnus doesn't consider this to be trivial, but I think we should definitely implement shortcuts to give quick access to important areas of every section, without exclusively relying on the TAB focus, which works in a list context but is not an optimal solution when outside a linear interaction pattern.

True.

Do you want me to mark my bug as duplicate of this and continue the conversation here, and cover all the other fields?

I'd prefer to keep the focus of this bug on exploring the feasibility of the particular implementation proposed (gmail shortcuts), which does not involve covering all the other fields. I think we'll have a hard time assigning non-localized shortcuts to all of these things, and I'm not even sure if we really want that. For some of them, current localized access keys might be quite sufficient and intuitive. A perfectly consistent solution may not be possible, and would certainly come with other disadvantages (e.g. losing the localization advantage).

We should really try if we can shuffle shortcuts around so that we can implement these. From many user reports, not having efficient keyboard access to CC / BCC field is a nasty deal-breaker for their daily routines, especially in the enterprise.

I agree, this is something we shouldn't dismiss as "non important".
I'll work on it!

This patch implements the following shortcuts:

Ctrl/Cmd+Shift+T --> To
Ctrl/Cmd+Shift+C --> Cc
Ctrl/Cmd+Shift+B --> Bcc

I removed the Ctrl+Shift+B shortcut to open the Address Book from the Composer window as I don't think that's a trivial accessibility entry point and not as common or as important as being able to quickly enable the Bcc field.
If we want to keep a shortcut for it, we could replace it with the letter "K".

All shortcuts are defined via fluent, allowing translators to adapt them.
Also, these shortcuts are defined via JS with a simple keypress eventListener, allowing more flexibility in the future if we will ever consider adding a customizable shortcut JSON Map.

The shortcuts are also visible via tooltip in the recipients labels, making it easily discoverable.

To is "always" showing, so no point wasting a hotkey on it.

The To field is closed if the user starts sending an email from a Newsgroup account.
It's also good to have it to allow quick focus to that field.

I could convert the compose window to top level <html> soon, then we should use title instead. The xul:label should be something else. I'm not sure if this is a button or what.

Right on! I was actually thinking about this.
Those labels can easily be converted into buttons.
I can do it right away so we can inherit the benefits of the title tooltips after the window is converted to top level HTML.

Hmm, but now that I look at this in detail, I see Alt+Ś is subject. Maybe we could just use Alt+T for to and Alt+C for cc? That is, use the accesskeys as they are + trigger opening it perhaps?

Mh, I'm not sure about this.
I wouldn't mind using those accesskeys as accelerators to trigger opening/focus, but that means removing the duplicates (eg. the Tools menu uses the Alt+T combination).
I'm okay with giving higher priority to the recipient fields.

Thomas, what do you think?

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

To is "always" showing, so no point wasting a hotkey on it.

The To field is closed if the user starts sending an email from a Newsgroup account.
It's also good to have it to allow quick focus to that field.

+1. And gmail parity.

Hmm, but now that I look at this in detail, I see Alt+Ś is subject. Maybe we could just use Alt+T for to and Alt+C for cc? That is, use the accesskeys as they are + trigger opening it perhaps?

Mh, I'm not sure about this.
I wouldn't mind using those accesskeys as accelerators to trigger opening/focus, but that means removing the duplicates (eg. the Tools menu uses the Alt+T combination). I'm okay with giving higher priority to the recipient fields.
Thomas, what do you think?

I think your patch as-is is just perfect. Alt+* combos would come with several issues:

• We explicitly want to match the gmail shortcuts, for an easy transition to Thunderbird.
• Having internationally identical shortcut keys is great for us and enterprise when it comes to support. (Note: Ctrl+Shift+* are localizable only in theory, we never want anyone to localize this because that will end up breaking all of our international shortcut keys.)
• We don't want to depend on access key localization for these high-value shortcuts: localization can easily break things, access keys are all over (contacts side bar, attachment reminder bar, etc.), so it's actually quite hard to get that right in every language, and from experience, many localizers won't get this right.
• As Alex said, let's avoid breaking the main menu access keys as long as we can.
• [Edit:] Ctrl+Shift+T/C/B are also convenient to use because both modifiers are on the outer left edge on the keyboard, allowing a very controlled double-handed usage without twisting your hands or risk of errors.

I think we should also start considering a more strict approach for those accesskey as we've been adding them everywhere.
It think Alt+... should be strictly used for Menu Bar items.
For UI elements, dedicated shortcuts with a consistent modifier should be used and showed in the tooltips.
With that we can also remove the ugly underscore letter in the UI, which should only be used in the menu items.

All:

As a user, I have been following this thread and the associated threads with much interest. I just want to say thank you for your efforts; they are most appreciated.

Mark Hepburn

Re Alt+, that is how accesskey works. People rely on knowing Alt+ what's showing will get them there. It's not only about menus.

(In reply to Mark Hepburn from comment #13)

As a user, I have been following this thread and the associated threads with much interest. I just want to say thank you for your efforts; they are most appreciated.

Thank you so much!

Shortcut and access keys are not localizable only in theory. They can, and will be different per locale.

(In reply to Magnus Melin [:mkmelin] from comment #16)

Shortcut and access keys are not localizable only in theory. They can, and will be different per locale.

I don't think that's true in reality.

• Shortcut keys should be the same for all locales.
• Only access keys are localized, exactly for that reason that they require underlined characters from the localized UI strings.

I have never heard of localized shortcut keys in Thunderbird. Can you provide an example?
Why would any localizer go through the hassle of having to change the whole set of shortcut keys when the original set is just fine and safe and also easier for support? Because as soon as you change one, you break many others, as they are virtually all taken.

There's zero difference between the Thunderbird shortcut keys of English and German localization:
https://support.mozilla.org/en-US/kb/keyboard-shortcuts#w_list-of-keyboard-shortcuts
https://support.mozilla.org/de/kb/Tastaturkuerzel_Thunderbird#w_liste-der-tastenkombinationen

Same for Firefox:
https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
https://support.mozilla.org/de/kb/Tastaturkuerzel

And here's the official reason (I'm sure there's best practices somewhere on MDN...):
https://developer.mozilla.org/en-US/docs/Tools/Keyboard_shortcuts

Because access keys are locale-dependent, they're not documented in this page. [From which it follows that all the shortcut keys listed are international, TD].

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

I think we should also start considering a more strict approach for those accesskey as we've been adding them everywhere.
It think Alt+... should be strictly used for Menu Bar items.

Alt+* only for menu bar items might be the automatical result of moving our code to HTML, where using the access key attribute effects Alt+Shift+* access keys by default (on Windows). We're currently in an unannounced phase of transition, with a bit of chaos and confusion. Executive summary: https://bugzilla.mozilla.org/show_bug.cgi?id=1661679#c6

For UI elements, dedicated shortcuts with a consistent modifier should be used and showed in the tooltips.

Anything which has a permanently visible string in the UI should preferably get an access key, not a shortcut key.
Exceptions may confirm the rule. You'll run out of shortcut keys very fast if you also give them to UI elements with a visible string.
Sometimes maybe there's a bit of room for rethinking this (as the current patch does, sort of), but trust me, that room will be very small.

With that we can also remove the ugly underscore letter in the UI, which should only be used in the menu items.

The ugly underscore is actually extremely helpful for efficient navigation. I'd much prefer a little ugly over less efficient, more so that one of the main reasons for using Thunderbird is ux-efficiency. I don't find the modern alternative, showing access key tooltips only when you press ALT key, all that attractive, but ymmv. (Try pressing Alt key in Windows explorer or probably any modern MS Office app to see that in action).

Anyway, we're digressing. I suggest to get this bug done first before we go into general design discussions... ;-)

(In reply to Magnus Melin [:mkmelin] from comment #14)

Re Alt+, that is how accesskey works. People rely on knowing Alt+ what's showing will get them there. It's not only about menus.

+1, with the transitional details of my comment 18.

So, what should we do with this patch?

Magnus' proposal: Use Alt+* for the shortcuts to keep it consistent with the accesskeys.
Thomas' proposal: Use Ctrl+Shift+* for the shortcuts to emulate the Gmail implementation.

For what it's worth, I would rather have Alt, it is just logical.

re: I removed the Ctrl+Shift+B shortcut to open the Address Book from the Composer window as I don't think that's a trivial accessibility entry point and not as common or as important as being able to quickly enable the Bcc field.
If we want to keep a shortcut for it, we could replace it with the letter "K".

Ctrl+Shift+K sounds a good idea because 'Alt K' set focus on address book in contacts sidebar. It would bring the two into alignment.

In the Write composer window :
Alt K is used to select/get focus on the Contact Sidebar 'address book' selection
Alt N is used to set focus in the Search Contacts.
Alt R sets focus on the 'FROM'
It would be reasonable and logical to assume:
Alt C selects Cc
Alt B selects Bcc

when needing to select where to move pills eg: move Cc to Bcc- on highlighted pill - press right click key (or Shift f10) to open drop down menu and press B
This works very well and also keeps a consistency with the association of B to Bcc.

'Ctrl' and 'Shift' is always something I associate with an external focus such as saving a file or sending an email, copy/paste, not internal window focus on items for selection.
Used together - well it also requires additional multikey selection and personally, I'd rather have much less of that. Those types of multikey are best left to selections that are more important if acted upon and so are made deliberately less likely to press accidentally.

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

So, what should we do with this patch?

Magnus' proposal: Use Alt+* for the shortcuts to keep it consistent with the accesskeys.

Alt+* = Access keys, which forces these "shortcuts" to be localized:

• they will end up different on every localization (imo, that's a disadvantage here)
• which is a nightmare for support and documentation, and not helpful for enterprise deployment.
• localization can break these keys easily (e.g. by not translating them, or overlooking duplicates)
• choose between breaking main menu access keys/other access keys OR using unintuitive access keys here
• furthermore, I would not introduce more important Alt+* access keys at this time as we might have to disbandon those if we switch to browser's Alt+Shift+* access keys.
• less convenient on the keyboard
• transition from gmail to TB made harder

Thomas' proposal: Use Ctrl+Shift+* for the shortcuts to emulate the Gmail implementation.

Ctrl+Shift+* = Shortcut keys. That will de facto (by Mozilla tradition) make these "shortcuts" internationally the same (typically not localized):

• easy for support and documentation, and helpful for enterprise deployment.
• localization typically won't break these as they won't touch them
• cannot break main menu access keys / other access keys or vice versa (as they are under developers' control)
• reasonably intuitive internationally
• does not affect localized access key design
• relatively convenient to use because both modifiers are on the outer left edge on the keyboard, allowing a very controlled double-handed usage without twisting your hands or risk of errors.
• transition from gmail to TB made easy

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

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

So, what should we do with this patch?

Magnus' proposal: Use Alt+* for the shortcuts to keep it consistent with the accesskeys.

Alt+* = Access keys, which forces these "shortcuts" to be localized:

• they will end up different on every localization (imo, that's a disadvantage here)
• which is a nightmare for support and documentation, and not helpful for enterprise deployment.
• localization can break these keys easily (e.g. by not translating them, or overlooking duplicates)

eg: MAC uses different words/keys etc anyway. eg: Alt/Option, Options/Preferences, and Cmd for most keyboard shortcuts.
I do not see how one shoe will ever fit all, but at least the differences are known and well documented.

• choose between breaking main menu access keys/other access keys OR using unintuitive access keys here

Not sure exactly which 'main access keys' you are refering to. I understand there is only one - opening of Address Book.
REplacement of Ctrl+Shift+K sounds a good idea because 'Alt K' already sets focus on address book in contacts sidebar. It would bring the two into alignment and make more intuitive. I see that as an improvement and ideally should be changed regardless. It also resolves the issue for using 'Alt' + B.

• OR using unintuitive access keys here.

Nothing is more non intuitive than suggesting 'Ctrl+Shift'. It's only intuitive if you use gmail and specifically on From, Cc. Bcc.
We should not be concerned with gmail.

Thunderbird uses the 'Alt + letter throughout the focus selection in the Write window.
Alt K is used to select/get focus on the Contact Sidebar 'address book' selection
Alt N is used to set focus in the Search Contacts.
Alt R sets focus on the 'FROM'
Alt C selects Cc ...............how is this not intuitive ?
Alt B selects Bcc

• furthermore, I would not introduce more important Alt+* access keys at this time as we might have to disbandon those if we switch to browser's Alt+Shift+* access keys.

Am I missing something here ? Why would anyone consider a switch to 'Alt+Shift', Thunderbird is not a browser and Why would a browser even consider to use 'Alt+Shift' as it is not a convenient double key action. That combination would be something rarely used as it is plain awkward.

• less convenient on the keyboard

Pressing just 'Alt' is not inconvenient. eg: 'Alt' + 'R' which selects 'From'.
It is much easier to only have to press 'one' key with one hand. Increasing the numbers of keys you need to press is not an improvement. You cannot assume everyone has ease of dexterity and not all keyboards have the Ctrl key in bottom left corner.

• transition from gmail to TB made harder

I'm more inclined to say the focus should be on loads of long time users of Thunderbird who would be seriously not amused to have to learn new habits.
Muscle memory is not that simple to adapt and changes that force this upon users are likely to get an unappreciated response.
There are already many complaints regarding the new 'Write' compose window and accessibility using keyboard. People in general do not like change and they are more inclined to be less positive when it comes to retraining after decades of status quo.
'Alt + F' selects From - which users are already using, it is a natural progression and intuitive for the adjacent buttons to be 'Alt +C' and 'Alt + B' with the C and B underlined.
Retraining all the valuable long term Thunderbird users because some users change from gmail (gmail users expect a change) seems incorrect.

• transition from gmail to TB made easy

I do not see this 'potential gmail customer' as a factor that should influence anything.
I believe we should be thinking more about Thunderbird's current users who do not appreciate needing to learn new habits that interfere with work throughput and are already trying to get to grips with version 78* and not thinking about potential gmail customers who would expect a change in learning when changing to a different product. After all they chose to stop using gmail.

(In reply to Anje from comment #23)

Thunderbird uses the 'Alt + letter throughout the focus selection in the Write window.
Alt K is used to select/get focus on the Contact Sidebar 'address book' selection
Alt N is used to set focus in the Search Contacts.
Alt R sets focus on the 'FROM'
Alt C selects Cc ...............how is this not intuitive ?
Alt B selects Bcc

All of these are localized access keys, so they will only apply to en-US localization. You'll be first person to suffer when supporting users because you will not be able to guess the localized equivalent of Alt+C for Finnish where it might end up as Alt+N for "CC" in Finnish. Having international shortcuts looks like a massive advantage to me wrt support and enterprise deployment, plus easy migration from gmail to TB.

• furthermore, I would not introduce more important Alt+* access keys at this time as we might have to disbandon those if we switch to browser's Alt+Shift+* access keys.

Am I missing something here ? Why would anyone consider a switch to 'Alt+Shift', Thunderbird is not a browser and Why would a browser even consider to use 'Alt+Shift' as it is not a convenient double key action. That combination would be something rarely used as it is plain awkward.

I agree that Alt+Shift+* is pretty akward. We're currently on auto-pilot wrt access keys. Check Preferences/options where Alt+Shift+* is used for access keys, just because this happens to be a Web page in a browser, and the Web standard has prescribed Alt+Shift+* for access keys (God knows why). We're changing our code to run on browser, so we need to take design decisions on this. On the upside, if we would use Alt+Shift+* as in-app access keys, they would be more distinct from Alt+* main menu access keys (i.e. we'd have a larger set of in-app access keys available).

• less convenient on the keyboard

Pressing just 'Alt' is not inconvenient. eg: 'Alt' + 'R' which selects 'From'.
It is much easier to only have to press 'one' key with one hand.

Alt+B, Alt+T and even Alt+C with one hand are pretty odd.

Increasing the numbers of keys you need to press is not an improvement. You cannot assume everyone has ease of dexterity and not all keyboards have the Ctrl key in bottom left corner.

I thought most desktop keyboards do...

• transition from gmail to TB made harder

I'm more inclined to say the focus should be on loads of long time users of Thunderbird who would be seriously not amused to have to learn new habits.

I'm not sure we can speak of habit interference here because so far, To/CC/Bcc have never been directly keyboard-accessible.
So all of these shortcuts are new.

Muscle memory is not that simple to adapt and changes that force this upon users are likely to get an unappreciated response.

Dito.

There are already many complaints regarding the new 'Write' compose window and accessibility using keyboard. People in general do not like change and they are more inclined to be less positive when it comes to retraining after decades of status quo.
'Alt + F' selects From - which users are already using, it is a natural progression and intuitive for the adjacent buttons to be 'Alt +C' and 'Alt + B' with the C and B underlined.
Retraining all the valuable long term Thunderbird users because some users change from gmail (gmail users expect a change) seems incorrect.

I'm failing to see the retraining as we've never had shortcuts for these fields. We won't indicate access keys on the labels, so it's not like anyone could expect to get CC from Alt+C - we're just adding dedicated shortcuts here because Alt+* access keys are a limited resource.
What you are forgetting is the main menu bar on top which usually requires a lot of Alt+* access keys already. If we force duplicate access keys inside the app, we're making main menu access harder (users would have to press and let go Alt first, then the menu access key). We can opt to do that, but so far this has never been discussed.

• transition from gmail to TB made easy

I do not see this 'potential gmail customer' as a factor that should influence anything.
I believe we should be thinking more about Thunderbird's current users who do not appreciate needing to learn new habits that interfere with work throughput and are already trying to get to grips with version 78* and not thinking about potential gmail customers who would expect a change in learning when changing to a different product. After all they chose to stop using gmail.

No, you're misunderstanding the situation. WE need to convince gmail users that changing to Thunderbird is something which is easy enough for them to take the plunge. A lot of young people have never heard of email clients as all they know is webmail, whatsapp, and facebook.

'Alt + R' selects From - which users are already using, it is a natural progression and intuitive for the adjacent buttons to be 'Alt +C' and 'Alt + B' with the C and B underlined.

The reasoning is now that those new selections are adcacent due to new design and Alt+R is currently used for the first item, it would be easy and intuitive to use Alt + C and Alt + B.
Although 'Alt' + 'C' is already used for opening 'Attachment Pane' - I always wondered why it was not 'Alt M' - mainly because the 'm' is underlined in Attachment Pane option via 'Menu Bar', 'Alt V' then 'M' opens it, but not via menu use 'Alt C', so I suppose that is something that would need modification.

I can see how the 'localisation' may be an issue, but in Support Forum I've not come across it so far, usually it's variants for OS eg: Mac. Maybe that's because I'm helping in the English variant.

So would you be saying to alter the current selection for 'From' from 'Alt'+'R' to 'Ctrl'+'Shift'+'R', so that it is intuitive and logical for the adjacent items to be 'Ctrl'+'Shift'+'C' and 'Ctrl'+'Shift'+'B' ?
Note:
'Ctrl'+'Shift'+'R' is already used to 'Remove main anchors' in Write window, so this could present an issue.
'Ctrl'+'Shift'+'C' is already used within the main menu for Calendar. Although obviously that would not operate with focus in the 'Write' window. Although I've often wondered why I can open the 'Address Book' so easily, but cannot do the same with the Calendar, but that is my arguement for liking to open things in windows and not tabs.
So, currently would not be a problem assuming there is no intent on opening the Calendar whilst composing an email; it was an option I would have liked to have seen added. Lets' hope no one decides to put the 'Write' window or 'Address Book' in a tab. Tabs are not always convenient and could mess up having identical key combos that provide two different actions.

'Ctrl'+'Shift'+'B' is currently used to open 'Address Book' - although it may seem logical to chnage to 'Ctrl'+'Shift'+'K' to be similar to address book selection in Contacts Sidebar.

I'm failing to see the retraining as we've never had shortcuts for these fields

But as described above, we have used those key combos for current selections, so retraining is not so much on the new keys as learning those current key combo functions will be different key combos and what the user is used to keying will do something they do not expect.
eg: expect to 'Remove main anchors' or open Address Book

Alex and I would like to create a consistent keyboard accelerator system for the addressing area, so we're trying to keep this in sync with:
Bug 1687432 - Provide no-brainer keyboard shortcut to easily move selected recipients between To/CC/BCC

After thinking about this and exploring various approaches, I think the original proposal from Thomas is the best approach to move forward.

Using accesskeys for those fields is not recommended because:

• They can be localized, making our documentation and support hard to handle.
• They can conflict with other accesskeys in the page (Attachment reminder, Contact Sidebar).
• They don't offer the flexibility we have when handling keystrokes in JavaScript if we need to handle edge cases.

Also, the Addressing Widget is a self containerized Custom Element with its own event listeners and behaviours, which are drastically different from a simple input field like the Subject.

I also found out that other webmail clients (Fastmail, Protonmail, Outlook web) use the same (like Fastmail) or very similar Ctrl+Shift+* combination to handle actions in the compose area.

In terms of discoverability, those shortcuts can be listed in the title or tooltiptext, making it discoverable for mouse users and screen readers.
For keyboard users, we can add those in the Menu Bar, underneath the View menu, with a text like Show and focus Cc with the acceltext listed to the right side.

I'll update the patch.

Patch updated implementing also the menu items underneath the View menu.
Those items are properly disabled in case the field is already visible.

I didn't add the eventListener for those shortcuts in the mail-recipients-area CE since that listener covers the entire document, and as recommended, a CE shouldn't leak or look for things outside itself.

I think this is a great usability improvement of the whole area.
I'm not sure if we should uplift this to 78 (if approved) as it comes with new strings.

After thinking about this and exploring various approaches, I think the original proposal from Thomas is the best approach to move forward.

Using accesskeys for those fields is not recommended because:

• They can be localized, making our documentation and support hard to handle.

I agree. Thomas has put a lot of thought into coming up with a good solution. (In reply to Alessandro Castellani (:aleca) from comment #27)

if (!(event.ctrlKey || event.metaKey) && !event.shiftKey) {
Something's wrong here, as this won't work as expected when Ctrl or Meta are pressed, but Shift is not, or vice versa.

Yup, silly mistake.

to-compose-show-addressing-field-key = T
This file is called messengercompose.ftl, so it's all about composing, so I think we can drop the -compose- hint and shorten the rest.

Magnus always recommends to use long and unique IDs for fluent strings since they're not self contained in their own file, and it's easy to conflict with other strings if the ID is no very specific.

Great suggestions for the Fluent file, I'll do them.

For the rest of the code updates, especially the method and variable name changes, aren't we going towards the same issue you pointed out in bug 1640760? The patch gets too big and the code clean up improvements shouldn't be done at the same time.

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

to-compose-show-addressing-field-key = T
This file is called messengercompose.ftl, so it's all about composing, so I think we can drop the -compose- hint and shorten the rest.

Magnus always recommends to use long and unique IDs for fluent strings since they're not self contained in their own file, and it's easy to conflict with other strings if the ID is no very specific.

Well, they are initially self-contained in their own file, but probably they end up in the same document.l10n object scope. Do we have any central design document which lays out such caveats and hints for general naming patterns?

I would still change:
addressing-field into
address-row

Great suggestions for the Fluent file, I'll do them.

For the rest of the code updates, especially the method and variable name changes, aren't we going towards the same issue you pointed out in bug 1640760? The patch gets too big and the code clean up improvements shouldn't be done at the same time.

So you are now beating me at my own game!? :-O

• Yeah, we can get away with using the existing function showAddressRow() (rather than showAndFocusAddressRow) to avoid an unrelated renaming spree (and maybe focus isn't all that special to require the longer function name). You are right, to focus on the essentials here and not bloat the patch, variable renaming can be outsourced.
• Event handlers should always have generic names like "someElementIdOnClick()" and not directly call a special function like showAddressRow(), to prevent mixups between the handler (only called for event handling) and the special function (which can be called from anywhere, and shouldn't have event handler stuff). Mixing the two tends to degenerate over time, and is harder to read in code because you won't know which event triggers the special function without checking in the layout layer.

Comment on attachment 9199659 [details] [diff] [review]
1667692-compose-shortcuts.diff

As I discovered in bug 1640760, this won't work in macOS as we need to use onkeydown in order to intercept the OS universal shortcut.

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

Comment on attachment 9199659 [details] [diff] [review]
1667692-compose-shortcuts.diff

As I discovered in bug 1640760, this won't work in macOS as we need to use onkeydown in order to intercept the OS universal shortcut.

Which Mac OS shortcuts are we intercepting (wrt OS functionality)?

The CMD+SHIFT+* combination is commonly used on macOS for some Terminal and man page quick actions, and CMD+SHIFT+B is used to send a selected file via Bluetooth.

Since we can safely assume that if Thunderbird is in foreground and focus, the user won't be able to interact with terminal or the finder, therefore we can intercept those shortcuts and do what we want.
Nonetheless, this is the default behavior of the XUL <key>, which overrides OS specific shortcuts.

Patch updated to work also on macOS.

Regarding the suggestion of having something like this:

to-address-row-label = To

to-show-address-row-label =
    .value = { to-address-row-label }
    .tooltiptext = Show { to-address-row-label } field

I think we should avoid it since we can't safely assume that this format will work in every language like it does for Latin based languages.
Better give translators the flexibility they need...I guess.

What do you think?

Screenshot: Fluent localization of a referenced term with grammatical cases
https://www.projectfluent.org/

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

to-show-address-row-label =
.value = { to-address-row-label }
.tooltiptext = Show { to-address-row-label } field

I think we should avoid it since we can't safely assume that this format will work in every language like it does for Latin based languages.
Better give translators the flexibility they need...I guess.

What do you think?

Well, it sort of depends on how good translators are with Fluent, or how good we guide them.
Fluent has been specifically designed so that you as a developer can ignore all the details of the localization, and it's up to the localizer to secure the correct grammatical forms. Fluent provides simple and explicit ways of doing that on the localization side.

In a strict sense (and correctly applying the concept of Fluent), what we want to achieve here is localizer attention to a specific fixed term (the field name), which should be used consistently throughout. The most explicit way of doing that is using the term as a reference whereever it's used. Grammatical cases can and must be handled by the localizer as shown in the screenshot above.

So it sort of boils down to the question if we trust our localizers to handle those details of fluent, and using references with grammatical casing. We can make it easier for localizers at the price of not having any explicit pointers to the fixed term, but either way we'll rely on localizer's intelligence to handle the fixed terms correctly. In a way it might be slightly easier for both sides (us and them) to skip the referencing and grammatical casing stuff, but I'm not sure if it's going to backfire when we end up with localized variations of what we expected to be fixed terms. Worse me may never notice if we don't know the target language, but users will be confused if terms are not consistently used...

I don't have a strong opinion on this.
Exploiting the Fluent concept correctly may provide higher accuracy in the long run.
It also reduces the maintenance workload of having to change many translations when a specific term changes.
Let's say if we rename "Attachment pane" to "Attachment area", with fluent casing/reference system you only change one string. Using our legacy system of flat translations without references, every string that involves "Attachment area" must be retranslated.

Comment is not exactly matching what it does (would have to be "Only do something if... and if ... is not a modifier).
Can we rewrite this as an early return (which is what the comment suggests)?

I wrote this not as an early return to avoid a cumbersome condition since we're handling both CTRL and CMD key, and one of these 2 modifier keys will always be false.
What do you think about this? Do you have a better approach to suggest?

if (
      (AppConstants.platform == "macosx" && !event.metaKey) ||
      (AppConstants.platform != "macosx" && !event.ctrlKey) ||
      !event.shiftKey ||
      ["Shift", "Control", "Meta"].includes(event.key)
    ) {
      return;
    }

I don't think this is needed, clumsy to read. We're not matching those keys below, so nothing will happen, even if the user let's go after pressing Ctrl+Shift. Not different from any other keys which we're not matching, like x, y, z.

keyup fires this event at every key, so even the modifiers trigger it.
I'd prefer to return it early and avoid running the switch.

Can you explain? Can Shift+Character not return the capital .key (T/C/B) for keydown event on some OS?
If possible, please eliminate the lowercase conversion.

Yes, on macOS the CMD+SHIFT+ modifiers don't affect the capitalization of the letter, therefore the event.key is always lowercase.
Forcing everything lowercase makes this work on all OSs.

Patch updated to address everything.
I also improved the fluent string by using a modular approach and avoid repetitions of the "Show {} field" string.

Here's a screenshot of my proposal to polish the menuitems.

The suggested changes are sensible, thanks.

Thomas already r+ this patch.
Magnus, what do you think about this implementation?

I personally find this great and very important from a UX point of view.

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

Created attachment 9205101 [details]
Screenshot: Polished menuitems (simplified labels, always enabled, trailing separator)

Here's a screenshot of my proposal to polish the menuitems.

This looks really good. Users will find that information intuitive to locate under the 'View' menu.
It is important to have menu items because there are users who do not use shortcut keys for various reasons. There are plenty of people who need a selectable menu item. We need to consider all methods that people use.
The menu items will also mean easy selection for those who use the keyboard arrow keys and enter.
It also offers information on what shortcuts keys to use for those who may prefer the shortcut method.

This design follows the natural generic and intuitive design utilised throughout other menu items, so will be easy to learn and discover. This is equally important for those who need continuity such as those suffering from Autism or where age can make it difficult to learn new things.

It will be easy for those offering help in the Support Forum to display that menu when offering support. Often, it is important to provide an image of where to locate information and this design will facilitate it as we can show the full path on what to select.

Thankyou Thomas for producing a workable design that everyone can use.

(In reply to Anje from comment #47)

It is important to have menu items because there are users who do not use shortcut keys for various reasons.
...
This design follows the natural generic and intuitive design utilised throughout other menu items, so will be easy to learn and discover. This is equally important for those who need continuity such as those suffering from Autism or where age can make it difficult to learn new things.

It will be easy for those offering help in the Support Forum to display that menu when offering support.
...
Thank you Thomas for producing a workable design that everyone can use.

Oh, I think we have to thank Alex, our UX lead, for the fine implementation of my idea and the useful addition of the menu items. It's a teamwork thing!

Thank you Anje for chipping in from a support and accessibility POV.

(In reply to Magnus Melin [:mkmelin] from comment #46)

But, I don't think you can add them as menu items. That part is very weird.

I think we need to approach this in view of Anje's comment, which illustrates that menu items are very important to provide access for users with special access issues. It's not just about making the shortcut keys discoverable. It's about providing a generic, systematic route of access for every feature through menus, which, as Anje pointed out, can be crucial e.g. for users with Autism, blindness etc. Providing menu access hence looks less like a design choice and more like a requirement for fully accessible software.

If you'd make them checkbox menu items it would be slightly better, but then
again, since you don't want to allow hiding with the hotkey, it doesn't
really work out with that either.

You are right that checkboxes would not work out well here, but I think the menuitems are needed and useful.

• I've tried to address the slight variance of the proposed menu items in my detailed review (comment 41), and from my careful analysis, which Alex found "sensible", we're not creating any UX problems here.
• Most users will use the keyboard shortcuts to show and/or focus these fields (but for other users menu access will be crucial).
• As we're not adding the checkmarks, it's obvious that you can only view/focus these fields via the menu, but not hide them (it's an always available one-way command, not a toggle). The logic seems fine: View > CC field - will always do just that.
• Menus provide localized keyboard access.

I recently came across this:
https://github.com/WICG/accessible-loading-and-searching-of-content/issues/5
Something like that could be a better approach to make such keys known.

That's a worthwhile idea to explore for shortcut discovery, whereas the menus are also needed for special needs accessibility.
Alex and I are both very sensitive when it comes to "weird" UX, so if both of us are happy, it can't be all that bad ;-)

We should not put them in the .ftl file then.

We already have some international shortcut keys in that file.
https://searchfox.org/comm-central/rev/0a5420357425c5fc45abf6d882e811ca79518113/mail/locales/en-US/messenger/messengercompose/messengercompose.ftl#56-57

Should we use the same approach and in a follow up but take out those keys from the fluent file?

We could create an array map for all those shortcuts.
That would also open up the gate for a future shortcut customization implementation.

What do you think about this approach?

Alex Arnaud (as a user depending on easy access), can you comment from an accessibility point of view?

To improve ux-efficiency in message composition, we're introducing 3 new commands, "Show and focus To field", "Show and focus CC field", and "Show and focus BCC field". They come with international keyboard shortcuts, Ctrl+Shift+T, Ctrl+Shift+CC, and Ctrl+Shift+BCC. On Mac, it's Command key instead of Control. When a field isn't shown, the command will show and and focus them. When a field is shown, it will just focus them, which is especially convenient via keyboard shortcut. So the net result is always "Field shown and focused". We're currently discussing ways of making these new commands discoverable and accessible.

• In the main UI, the commands will be available from the address row disclosure buttons (CC/BCC) on top of the "To" address field. The "To" button will usually not be shown unless it's a News account. The buttons have a tooltip which mentions the respective keyboard shortcut.
• Alex and I have proposed to make these commands and their shortcuts easily discoverable and accessible via the main menus: View > To field / Cc field / Bcc field. Using the menus (as explained above) will always show and/or focus the field. Hence the commands are never disabled, and do not have a checkmark as you cannot toggle them off like, for example, Contacts Side Bar.
• Magnus doesn't want to have these commands included in the menu as he believes that they are "not really a command at all" and he finds them "weird" because they work a bit different from the classic toggle buttons in the View menu.

Here's our question:

• How important is it for users depending on easy access (blind, autist and other special needs) to have these commands accessible in the View menu? Also considering that the shortcut to focus the "To" field will not be discoverable unless you've set up and are using a "News" identity.

For more background, you may want to read Anje's comment 47, my comment 48, and Magnus' comment 51.
Tia for assisting us with the accessibility evaluation.

@Alex Arnaud, attachment 9205101 [details] has a screenshot of the proposed menu entries in the View menu, iirc you once mentioned that you're still able to see things. The menu entries would obviously advertise the shortcuts, too, and have localized access keys.

Just redirecting the n-i to Jean-Philippe and Valentin.

I am moving, I don't think I'll have the time to handle request this month.

All right, let's try again with this patch.

Menu items and Shortcut discoverability

• The View > To Field etc, menu items are disabled if the field is already visible, since that command semantically doesn't make sense (View something that it's already visible).
• The shortcuts are listed as tooltip text for the button labels in the addressing area, and as accelltext in the menu items to be easily discoverable by both mouse and keyboard users.

Adding accesskeys

• I added accesskey attributes to the fields label because that's the correct thing to do. Since those fields are a representation of a Form, we should offer Alt+* quick access as we do for the other fields in the addressing area.
• Those accesskeys are not connected to the shortcuts, making them easily translatable.
• Users will know that they can quickly focus on those fields like a normal form, without making things complicated for us to teach them that Ctrl+Shift+* also focuses. That's a side effect of revealing a collapsed field, nothing more.
• The To label accesskey interferes with the Tools menu item. I don't see this as a big problem because we can consider changing the Tools accekey, that menu item has objectively a lower priority in terms of access compared to the To field, this conflict wouldn't be constant and translators can handle it independently from the JavaScript code.

Shortcut keys listed in an array

• This allows us to declared those keys once and reference them whenever we need (on keydown, when setting up menu item strings, etc).
• In future iterations, it will be super easy to allow shortcut customization since we can simply replace that array in one place.

I consider this an optimal solution, offering discoverable international shortcuts on par with Gmail, and maintaining localized accesskey for all our form fields.

OT: Here's some anecdotal evidence for my claim that localization can easily break things if you give them a chance: Bug 1696623 Comment 0. That localization (Czech) gave the same access key (Alt+S) to File menu, Search contacts, and the BCC button (the last two conflicting in contacts sidebar).

This should use https://searchfox.org/mozilla-central/source/toolkit/modules/ShortcutUtils.jsm

Coming back to this, and also looking at bug 1616514, I think we could do it like this.
Wontfix bug 1616514 as far as options are concerned. In this bug, add the View | To, Cc, Bcc menu items

• as checkbox menuitem items
• persist the menu item checkbox choice for cc and bcc (but always show To on new)
• through the menu when clicking: allow the fields to be toggled off unless they have content in them
• when using the hotkey, don't toggle closed, just focus

Sorry, but I don't think this is a good UX approach.
Doing this creates some unpredictable inconsistencies that are hard to discover.
Reveal a field, but if it's visible hide it, but if it has content just focus it but never hide it, then make it persistent if shown.
It feels a bit too convoluted, I think we should step back and make it simple.

bug 1616514 is a thing on its own, which is "Allow users to make CC and BCC fields always visible per identity", and I think we found a good solution with the last patch from Thomas.

This bug is purely for keyboard accessibility, which is "Add an international keyboard shortcut to the CC and BCC field to allow quick opening".
The quick focusing is a consequential benefit, and showing those shortcuts in the View menu and tooltips is for total discoverability.
For this, I think we shouldn't disable the View menu items, nor make them checkboxes, but leave them as they are to guarantee that users can always select those items even if the field is already visible.

I don't know about the accesskeys...

Indeed, that's not great. I'll remove them.

I don't see how an object would make things better...

Replaced with simple variables, thanks.

I don't actually see where this tooltip is shown.

The "To" tooltip is shown when the user has a news identity selected, and the To label appears in the extra recipients list. That tooltip is also read by screen readers.

(In reply to Magnus Melin [:mkmelin] from comment #60)

This should use https://searchfox.org/mozilla-central/source/toolkit/modules/ShortcutUtils.jsm

That's neat, but if I'm not wrong those helper methods only work with a XUL <key> ID, which we don't use as we're doing everything with pure JS.

Patch updated and added a simple test to cover these scenarios.
Try-run: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=1b36e35e79e44b6093be9acb3f697ab93cf1a5cf

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/24c20603478a
Implement keyboard shortcuts to show and focus importat addressing fields. r=mkmelin, r=thomas8