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

Bug 440377 introduced the new mail-address-pill Custom Element, which drastically changes User Interface of the entire recipients header area.

Let's use this bug to track the improvements and changes necessary to refine and polish this new implementation.

Todo:

• Make Cc, Bcc, Reply-to, etc... last visibility state persistent within user profile

So for example, if a new message is composed and Cc field enabled/shown, after sending the message and clicking Write button again to write a new message, the Cc field would already be enabled/shown already without having to click again on the Cc link/button to do so...

This bug also follow discussion from here https://thunderbird.topicbox.com/groups/ux/T320a92088a949458-M75042b7ac03e94370d7947c6/work-started-on-redesign-recipients-address-fields-to-cc-bcc-etc and here https://thunderbird.topicbox.com/groups/ux/T37151b06e9361fac-M2867c2e78ae8282fd6394b42/work-started-on-redesign-recipients-address-fields-to-cc-bcc-etc

Maybe related?
bug 1613090

Maybe related?
https://bugzilla.mozilla.org/show_bug.cgi?id=1613090

Nope, this is completely unrelated as it's dealing with the new UI implemented in 73. Your bug is related to the current widget in 68.

So, the requests and consequential solutions might be 2:

• Add a Pref to always show CC and BCC open when composing a new message, or
• Remember the previously opened rows and show them opened again when composing a new message.

Is this actually useful?
Are we adding a preference just for some edge cases which are not the norm?
Is any other email client doing something similar?

I personally find it odd to not having the compose message resetting the UI to its default when opening a new window.
And opening those extra fields is only 1 click away, and we're trying to improve their location and reachability in bug 1616155.

Magnus, Richard, what do you think?

• Remembering states for next time is usually causing more problems than it solves
• Remembering states of typed recipient fields from a random message for all accounts and identities ("user profile" = TB profile?) is definitely a bad idea.
• Alessandro is right: compose UI must come with predictable default states rather than remembering accidental per-message choices
• Allowing user to define his own per-identity preferences about visible recipient fields is a good idea, that could definitely be useful in a variety of scenarios.
• Bandaid implementation might be dead-simple for the default case of CC/BCC, using existing auto-cc / auto-bcc prefs.

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

So, the requests and consequential solutions might be 2:

• Add a Pref to always show CC and BCC open when composing a new message, or

We already have that pref: auto-cc / auto-bcc.

mail.identity.id1.doCc;true
mail.identity.id1.doCcList;cc@recipient.com
mail.identity.id1.doBcc;true;
mail.identity.id1.doBccList;bcc@recipient.com

We could simply tweak our handling of those two double-prefs:

• when user checks "CC these email addresses" (Account Settings > Copies & Folders), set mail.identity.id1.doCc;true even when no auto-cc address is specified (currently, we seem to auto-add the account's default address if left empty, which is pretty wrong anyway).
• check mail.identity.id1.doCc for new compositions, and show CC row if true; same for BCC by analogy.

Iow, checking auto-cc / auto-bcc in account settings without specifying an address will show the respective rows when composing with that identity.

• Remember the previously opened rows and show them opened again when composing a new message.

No, we should not do that. See above.

And opening those extra fields is only 1 click away, and we're trying to improve their location and reachability in bug 1616155.

Even though we haven't offered this feature so far, and regardless of what other mailers are (not) doing, it's easy to see that this can be a regular scenario e.g. in business settings: when sending messages, always CC the responsible person (which might differ per message, so auto-CC wouldn't do the trick). 1 easily avoidable extra click for every message is a lot of clicks, and we are here to excel.

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

So, the requests and consequential solutions might be 2:

• Add a Pref to always show CC and BCC open when composing a new message, or

Outlook for example shows always the CC field. So users could like to be able to configure to show this field always.

• Remember the previously opened rows and show them opened again when composing a new message.

No, this shouldn't be done.

(In reply to Richard Marti (:Paenglab) from comment #6)

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

• Remember the previously opened rows and show them opened again when composing a new message.

No, this shouldn't be done.

Could someone explain why this should not be done? Because I still don't understand...(and I read all comments :0)... sorry guys!

If it is the user preference why it should not be achievable? Shouldn't it be user choice in the end? And TB excel in empowering users?

Perhaps preference already exists as per Thomas D Comment 5 (but not too fan of having it done per identity, I would tend to think it may complicate thinks and potentially lead to inconsistent behaviour in the UX), or perhaps it could also be achieved by storing one binary number in one preference field (instead of one per each optional fields to limit the number of preference to implement and manage) in the TB user profile somehow, where each bit position would correspond to an optional field and value to the visibility status (0=hidden,1=shown) so if you have three fields Cc Bcc Reply-To for example a number such as 011 would means that Cc (bit far right) Bcc (middle bit) are shown by default when writing a new message why Reply-To (bit far left) would be hidden by default. in principle, more bits could be added to the left as more optional fields are made available...

The stored value being updated each time an optional field is hidden or shown by end-user in the compose window... it could be as "dead simple" as that... this also mean it can easily be disabled at any time by user choice/preference directly from the compose windows without having to go in the Options panel or advance config editor...

Is that really that difficult to implement and maintain technically?

All that is needed really is remember the last visibility state, as well as having a way to configure it... it could but just as easy as allowing to set one number preference advance editor or via policy...

If you think it should not apply to all users, perhaps set/create a preference configurable via advance config editor to allow enabling persistency for the optional fields... for all advance users out there...

Why do we always have to compare with other email client out there, why Thunderbird cannot come with its own feature that no one implement yet? It is a good to get some ideas from others perhaps but it does not mean they cannot be expanded from there... I haven't checked in all email clients, but I am pretty sure that in Outlook Cc is always visible by default and Bcc ones activated remained active within the user profile at all time unless end-user disable it... Not that it should be an example though but still :-)

I can't tell about possible other field such as Reply-To, Newsgroup etc... as I don't use them in all honesty, maybe state persistency for those may not be needed but definitely Cc and Bcc last visibility state shall be made persistent and be a user easy choice to have them shown by default or not... when writing new message... those field are commonly used...

When you write 20 or more emails per day... it is really annoying to have to click all the time on Cc or Bcc to have those fields visible first... software should be helping tools not being on your way...

I understand that for grandma 8.0 or newbie 0.1 the interface must be uncluttered but for daily heavy-duty user 3.0 it must be functional and straight to the point... less repetitive clicks, the better... don't you think?

(In reply to Richard Leger from comment #7)

(In reply to Richard Marti (:Paenglab) from comment #6)

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

• Remember the previously opened rows and show them opened again when composing a new message.

No, this shouldn't be done.

Could someone explain why this should not be done? Because I still don't understand...(and I read all comments :0)... sorry guys!

Like Thomas wrote in comment 5 the first two points, remembering the last state from a random message isn't good. This is not against a pref for the defaults, only about the remembering the previous state. Or do you want, when you follow-up a news message have this follow-up field in a normal message?

Agreed remembering would cause lots of problems. I think a pref would likely be quite redundant, it's easy enough to add the cc if you need it. We should really strive for simplicity.

The complexity behind implementing something like this goes deeper than it seems.
I'll try to list all the case scenarios with can encounter, alongside downfalls and issues, but as usual we're probably missing some more cases.

Remember the state of the opened recipients

• The user opens the message compose and enables Cc and Bcc.
• The user opens a new message and finds those fields open even if it doesn't need them, making the header area taller for no reason, so it closes those fields.
• The user replies or forwards a message with extra recipients, since the compose window gets opened and those extra fields are visible, we update the stored value.
• The user opens a new message and finds again those fields open even if he didn't actively revealed them.
• The number of visible and usable fields changes based on the type of account (imap/pop, nntp).
• The amount of extra recipients is not fixed as it can increase or decrease based on custom Headers used by the recipients, so to store that value we need to serialize it, and since those extra Headers can be deleted, we can stumble upon a discrepancy between our stored value and the number of available recipients.

Do you already see how many conditions and possible callbacks we will need to handle and maintain for the sake of having an option to "not waste a second to click on the Cc label".

Pref to always show Cc and Bcc on compose

• Do we handle it globally or per account?
• Maybe a user has multiple accounts and wants this only on one of those.
• What about Reply-To? Do we allow always showing that?
• What if the user has some custom Headers and wants to always show those as well?
• Is it OK to always show those fields even during replies, even if not used?

Also here, we'll need to handle various conditions and exceptions, just to avoid a click.
Overall, this approach makes the message header too tall by default and I prefer to avoid it and let the user control the fields per email.

When you write 20 or more emails per day... it is really annoying to have to click all the time on Cc or Bcc to have those fields visible first... software should be helping tools not being on your way...

Removing this annoyance will introduce much more complexity and overhead on a section which is already pretty complex.

I understand that for grandma 8.0 or newbie 0.1 the interface must be uncluttered but for daily heavy-duty user 3.0 it must be functional and straight to the point... less repetitive clicks, the better... don't you think?

We should step away from these distinctions and grouping based on experience.
A good UI is intuitive, clean, and easy to use for every type of user, and adding these options will introduce many layers of complexity whic is not our objective.

For me this is a WONTFIX.

Evidently that is your call and you may be better placed to make it... though it is still hard to be convinced by your argumentation... one may wonder if any existing feature in TB may have not be far more complexed to implement than this feature request...

Could then at least the Cc field be made visible by default all the time... as a possible compromise?

I don't believe that would be much of a clutter nor difficult to implement... Thunderbird is primarily an email client software afterall...

Hoping you would at least consider it...

(In reply to Richard Leger from comment #11)

Could then at least the Cc field be made visible by default all the time... as a possible compromise?

Well no, that doesn't look like a compromise, more like forcing the use case of one group on all groups of users, at a high cost.

I don't believe that would be much of a clutter nor difficult to implement... Thunderbird is primarily an email client software afterall...
Hoping you would at least consider it...

Richard Leger, it's unfortunate that your summary is focused on one particular implementation ("remembering") instead of just describing your use case and the generally desired outcome. Remembering is not a solution because again it would just push the problem to other groups of users, hence WONTFIX for that particular proposal (please accept that). I think what you are really asking for is any way of defaulting to certain fields open at composition start (esp. CC, BCC, Reply-To), which is a very legitimate RFE with plausible use cases (as hinted in my comment 5).

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

For me this is a WONTFIX.

• Yes, "Remembering the state of open recipient fields" (per current summary of this RFE) looks WONTFIX.
• I think reporter is really looking for any way of defaulting to certain fields open (CC, BCC, Reply-To), which looks like a legitimate ux-efficiency RFE.
• I'm not sure to what extent implementation-level arguments should prejudice this, because the private and enterprise use cases are obvious, as I hinted in comment 5. It's ok to say "not now, maybe later" or even "not us, but we'll accept a patch".
• Remembering, global or per-account pref (in the strict technical sense) are NOT useful.
• Per-identity pref covers per-account, is useful and imho not very complex to implement. Single identity.default pref which self-duplicates as required. I think the desired behaviour and implementation using identity pref is probably less complex than comment 10 suggests.

I'd appreciate if someone could comment on my proposal of comment 5, which looks like an acceptable, low-cost compromise for now:

• Tweak behaviour of existing auto-cc and auto-bcc prefs so that when they are checked, but no auto-cc/bcc recipient specified, we'll just ensure that the respective (potentially blank) recipient input field is open. We already do that per-identity, only we don't allow auto-cc/bcc without specifying recipient(s). That would allow us to cover the most likely scenarios of this bug per-identity without adding any new prefs, UI, nor much complexity, and presumably pretty easy to tweak the existing implementation into handling empties.

Comments?

Here's the existing UI which we can use without any changes to allow defaulting to CC/BCC field shown for any given account/identity. Just minor tweaks of behaviour to accept not specifying recipients here.
For details, see comment 5.

I'd appreciate if someone could comment on my proposal of comment 5, which looks like an acceptable, low-cost compromise for now:

• Tweak behaviour of existing auto-cc and auto-bcc prefs so that when they are checked, but no auto-cc/bcc recipient specified, we'll just ensure that the respective (potentially blank) recipient input field is open. We already do that per-identity, only we don't allow auto-cc/bcc without specifying recipient(s). That would allow us to cover the most likely scenarios of this bug per-identity without adding any new prefs, UI, nor much complexity, and presumably pretty easy to tweak the existing implementation into handling empties.

Comments?

Not sure if your request for comments is for end-users or dev team... but here is my view...

Such solution (Comment 5) would be acceptable from end-users point of view... I am not too fan of the per account settings but if that is the only way to achieve it, it is much better than nothing...

My intention has never been "forcing the use case of one group on all groups of users" but that is currently what you do on the group of TB users I belong to... dealing with large amount of emails on daily bases... that wish some fields to be visible at all time by default... I understand the idea of simplifying and un-cluterring the UX, it is a good idea and goal that I support... but not to the detrimemt of practicality and efficiency... the less click the better... at least for some of us.

As said previously, if there is an option in Setting or Advance Config to allow end-users to make those fields (at least Cc and/or Bcc) always visible in user profile (or per account) by default without hindering the default for others then that is fine. It could be simple as providing a pin icon next to the cross icon used to delete the field... or via the settings suggested by Thomas (Comment 5)... worth considering...

But such option shall be made available to end-users (I would certainly not be the only one requesting it out there) so end-users can decide on their own without being forced one way or another... by the design decision...

Such option/flexibility should be a core feature of TB...

But in the end it is the dev team choice...

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

I'd appreciate if someone could comment on my proposal of comment 5, which looks like an acceptable, low-cost compromise for now:

• Tweak behaviour of existing auto-cc and auto-bcc prefs so that when they are checked, but no auto-cc/bcc recipient specified, we'll just ensure that the respective (potentially blank) recipient input field is open. We already do that per-identity, only we don't allow auto-cc/bcc without specifying recipient(s). That would allow us to cover the most likely scenarios of this bug per-identity without adding any new prefs, UI, nor much complexity, and presumably pretty easy to tweak the existing implementation into handling empties.

FWIW, I like this idea, and in general, I like the idea of providing for these more 'power user' type features and flexible configurations. That kind of flexibility is a reason people use a dedicated desktop client. As I see it the default UI should be simple and straightforward for the more common use cases, but it should be possible to tweak and customize, even if it takes some digging into prefs and settings etc.

In my humble opinion I think that all fields should be shown by default.

(In reply to Marco A.G.Pinto [:marcoagpinto] from comment #19)

In my humble opinion I think that all fields should be shown by default.

No, we won't do that. Already the addressing area is huge, many users may never need CC/BCC, so it's not a good default for everyone. Google doesn't do that either.

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

(In reply to Marco A.G.Pinto [:marcoagpinto] from comment #19)

In my humble opinion I think that all fields should be shown by default.
Google doesn't do that either.

This is a false argument... It is not because Google does not do it... that TB does not have to!
While it is good to get inspired by other solutions, it does not mean that TB dev team has to follow it like some sort of a dogmatic! TB does not have to become Gmail interface... please don't!
Gmail is not a great example in term of UX and usability... especially for advanced users when you are acquainted with current TB "super powers" in term of management of emails :-)

That said the understanding here was that it would not be showing by default, but for those who want it, it would be possible to show those fields by default via a setting... is that no longer the case?

(In reply to Richard Leger from comment #21)

This is a false argument... It is not because Google does not do it... that TB does not have to!
While it is good to get inspired by other solutions, it does not mean that TB dev team has to follow it like some sort of a dogmatic! TB does not have to become Gmail interface... please don't!
Gmail is not a great example in term of UX and usability... especially for advanced users when you are acquainted with current TB "super powers" in term of management of emails :-)

I couldn't agree more! GMail is OK for private use, but still if TB was about to convince people it must be better than Gmail (and let's ignore native vs web) - TB should have means to let users decide how they want to work with their emails. I understand that there are some 'fashion' trends and TB should reasonably follow them, but not in the way that it just mimics GMail. GMail is not a holly grail - it is OK to be inspired by GMail et al, but reasonably, otherwise we will end up with one big text area with big letters and huge send button.

That said the understanding here was that it would not be showing by default, but for those who want it, it would be possible to show those fields by default via a setting... is that no longer the case?

+1

What's more, the UI for Composer could have something 'yes, keep this available next time'-like button if designers wanted to avoid cluttering preferences too much. This setting should be tied to an account of course. The main benefit of TB (despite being native) is that it allows to have multiple accounts, each one can have a different usage - some are rather private (a no CC/BCC is required), others can be more (semi-)business oriented (CC enabled).

To recap, let's try to put hats of a generic user - a couple of private accounts, a couple of business/official accounts. The user should be able to adjust each one of the accounts for their needs. A default configuration can be super trendy, but let more advanced/demanding clients to reconfigure.

(In reply to piotr.skowronek from comment #22)

(In reply to Richard Leger from comment #21)

That said the understanding here was that it would not be showing by default, but for those who want it, it would be possible to show those fields by default via a setting...

Yes, I'll attach a patch for that just now - essentially to allow using the existing auto-Cc/Bcc feature pref from account settings without specifiying auto-recipients (my comment 5; screenshot attachment 9130451 [details] from comment 14).

To recap, let's try to put hats of a generic user - a couple of private accounts, a couple of business/official accounts. The user should be able to adjust each one of the accounts for their needs. A default configuration can be super trendy, but let more advanced/demanding clients to reconfigure.

+1, my thoughts exactly.

This patch provides a versatile low-cost solution to this popular feature request.
4 duplicates and several user voices from our UX and support communication channels have requested the same, especially for enterprise contexts. UX-efficiency matters!

Richard, could you check if this works as designed? (see "How it works" below).

Essentially, this patch simply allows using the existing auto-Cc/Bcc feature pref (mail.identity.id#.doCc/.doBcc) from account settings without specifying auto-recipients (my comment 5; see screenshot attachment 9130451 [details] from comment 14).

How it works:

• ≡ > Account settings > Your account > Copies and folders > [x] Cc these email addresses: [___________]
• tick the checkbox but leave the input blank, which will just show the empty address row when you start a composition with that identity, or change identity in the compose window.
• In compose window, changing from an identity with Auto-Cc checked, but empty, to another one with Auto-Cc unchecked should remove CC field if empty.
• Bcc by analogy.

(In reply to piotr.skowronek from comment #22)

To recap, let's try to put hats of a generic user - a couple of private accounts, a couple of business/official accounts. The user should be able to adjust each one of the accounts for their needs. A default configuration can be super trendy, but let more advanced/demanding clients to reconfigure.

I'd suspect that Reply-to is much more likely to be preset with a fixed address, and it can't be fixed the same easy way to show up empty. CC and BCC are the low-hanging fruits, and more mission-critical.

My cleanup in Bug 1646857 - Refactor/simplify nested conditionals code in LoadIdentity() prepared the ground for this.

Comment on attachment 9178125 [details] [diff] [review]
1616514_acceptEmptyAutoCcBcc.diff

Is this patch mostly intended for 78? If yes, I could give a ui-r+ for 78 because we can't add new strings.
But for later versions we should do a clearer solution because this functionality is very hidden with this patch.

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

How it works:

• ≡ > Account settings > Your account > Copies and folders > [x] Cc these email addresses: [___________]
• tick the checkbox but leave the input blank, which will just show the empty address row when you start a composition with that identity, or change identity in the compose window.

This is the problem: when you tick the option, the address is automatically filled and you have to delete it to get the planned function. And without special Information in release notes (does anybody read them?) or mailing lists, newspapers ;-) nobody is aware of this. Maybe only the followers of this bug.

For future TB versions I think we should add special options to enable this functionality in Composition & Addressing as this is a compose functionality and not a Copies & Folders one. Yes, you could come with "Cc and Bcc are copy functionalities", but only when a default address is entered. Without, it's only an option which can, but not must, be used.

With this separation, the old behaviour stays as it is and we have clear options to show the rows.

If I may suggest...

(In reply to Richard Marti (:Paenglab) from comment #28)

Is this patch mostly intended for 78? If yes, I could give a ui-r+ for 78 because we can't add new strings.

A "quick fix" should be implemented for 78.x ESR branch... if the current patch do the trick... there is no reason not to do for sake of current users using 78 ESR.

But for later versions we should do a clearer solution because this functionality is very hidden with this patch.

Then a better proper solution could be put in place for later version by next ESR in a follow-up bug? Some people suggested that a separate display options be available for each field with a quick way to pin/unpin permanently via the UX in Compose Window... worth (re)considering perhaps... though on a per profile, per account, per identity remain valid question...

Ability to set such option(s) via policies would also be a must for organisations that would want Cc,Bcc displayed by default for all users...

I think this feature might not be desired/needed. Clicking the cc/bcc button is the same amount of clicks as clicking to get to the field. In 68 where things were different, cc/bcc also didn't "show" by default.

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

I think this feature might not be desired/needed. Clicking the cc/bcc button is the same amount of clicks as clicking to get to the field. In 68 where things were different, cc/bcc also didn't "show" by default.

Multiple people already mentioned that No it isn't the same!
Again we are not asking for it to show by default for all users, just having the possibility to do so for those that want to, in a simple and easy way...
Really don't understand what is your (You/Council/Tech committees) problem with such feature request... especially considering it is already possible to implement easily in 78.x branch... as proposed by Thomas D.

Like already recognized above, it's a hack of a solution, and it's not clear we'd want to do something more elaborate either.

Just because people think they want something doesn't necessarily mean they actually do. It's part of our job to figure out what is actually the best solution for things, not implement them blindly. "Because it's not the same" is simply not a good reason to implement anything.

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

Like already recognized above, it's a hack of a solution, and it's not clear we'd want to do something more elaborate either.

Just because people think they want something doesn't necessarily mean they actually do. It's part of our job to figure out what is actually the best solution for things, not implement them blindly. "Because it's not the same" is simply not a good reason to implement anything.

If I may, as a user at the enterprise level and as one who submitted a bug report, the issue for me is that I routinely use both the BCC: and the CC:

I write typically 80 to 120 emails a day, and reply to many more. When composing, I'm composing to teams for which I have created lists, but I often CC: others who aren't on a team list but need to be considered stakeholders. Thus, I'd say that about 80% of the time I'm including a CC: in an email.

I create and disseminate corporate policy and can tell you what it is that I would very much like, which is for an option for the CC: field to default to being open without clicking something. I'd also like it to be empty. Currently, the product as patched presents a CC: field with my email address populated. Which I now tab over to and backspace to delete. Better but not ideal. Still, I can use the keyboard rather than reaching for the mouse to initiate, compose and send an email. In a perfect world, I'd nit [CTRL-M], move about, create a message, then hit [CTRL-Return] and be done with it.

I truly appreciate the thought being put into the process, and the opportunity to weigh in. One rarely has the opportunity on a platform that means so much to them. Thanks!

Mark

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

I think this feature might not be desired/needed. Clicking the cc/bcc button is the same amount of clicks as clicking to get to the field. In 68 where things were different, cc/bcc also didn't "show" by default.

Yes, because showing empty rows of a certain type would have been very difficult, error-prone, and peculiar in TB 68 single-row design. We want to be better than TB68, so comparing to TB68 may not be the best measure. Also, for a CC/BCC field which is already open below the To field, even mouse users will typically just press Enter to get there, so just counting clicks may not be appropriate (more details below).

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

Just because people think they want something doesn't necessarily mean they actually do.

I hear you, and that's true sometimes, but I think if several power users concur on the same request, it should be carefully considered.

It's part of our job to figure out what is actually the best solution for things, not implement them blindly. "Because it's not the same" is simply not a good reason to implement anything.

I think the motivation for this RFE is beyond habit formation; this is about everyday ux-efficiency, workflows, and convenience for a highly frequent scenario in one of the most used and important areas of our UI.

The motivation for this RFE are real-life scenarios where business users need to CC someone for most of their messages, but do not know in advance who this will be, so auto-CC won't do the trick. So they really want a blank CC field open at composition start, for maximum efficiency/convenience, even as a reminder. E.g., a 1st level support person might have a regular task of escalating issues to an appropriate person of 2nd level support via CC whilst replying to the customer. So the person CC'ed isn't known in advance, but varies for each use case, but the fact that CC is used regularly is known. I think it's very obvious that one extra click for such frequent basic scenarios is time-consuming, workflow-breaking, and just extremely annoying. And that's exactly what our users are reporting here - we need this like every time.

Counting clicks & evaluating ux-efficiency (The small print)

• Mouse and keyboard users: With an already open CC/BCC field (this RFE), you can just press Enter from To field to get there. That's maximally ux-efficient, intuitive, and convenient. Anything less than that is extra effort and/or extra steps, for every single message which requires CC/BCC.
• Keyboard-only users: Having to Shift+Tab to CC/BCC buttons is not very convenient nor intuitive, even though we have good reasons for the button location. It takes a lot of attention and mental processing to understand that you have to navigate backwards, and exactly how many times are needed to get there.
• Mouse-only users: Just click-counting isn't enough, targets matter. Even for a mouse-only user who stubbornly refuses to just press Enter even though he's already typing in To-field, it is way easier to click on a big CC/BCC row below vs. having to navigate upwards exactly to that smaller click target of CC/BCC button and click there.

Like already recognized above, it's a hack of a solution

• Imho, hack or not wouldn't matter much as long as we serve our customers. It's not a bad, dangerous, or costly hack which will cause big headaches in the future. Yes, every line of code has a cost, but if we start using the general "maintenance cost" argument against legitimate RFE's, we would have to eliminate most of the very features which make Thunderbird popular because it's versatile. By analogy, I hope no-one would suggest that we should stop listening for Enter to move from one field to the other, which also isn't needed in a strict sense as you could just use Tab, so arguably supporting Enter is just extra cost.
• What really matters is the cost-benefit ratio, which is excellent for Enter as well as for this RFE.
• I do not fully agree with Richard's negative view on discoverability. I think this feature can be reasonably subsumed and discovered with a bit of effort under Copies and folders, because it's about adding regular unknown (B)CC's, which isn't significantly different from adding regular known (B)CC's.
• We can easily make this feature more discoverable by changing the placeholder text or adding a tooltip. I think adding an extra string should not be considered a problem - if we found a totally wrong string in the UI, we'd also fix that swiftly, wouldn't we? But even without extra strings, affected users have already indicated that they need this so desperately that any solution, discoverable or not, will be fine with them.

and it's not clear we'd want to do something more elaborate either.

Well, Richard as an UX person suggested that, and from the user feedback we have here, it may look worth exploring.

• Any business which regularly uses custom headers (aka "other headers" via pref) for whatever reason, will certainly appreciate not having to do extra clicks every time for that row to be open, but just use Tab or Enter for navigation.
• Alex and I would certainly be able to figure something out with a simple UI, yet scalable and versatile.
• It's more work, and harder to implement, that's why my proposal fixes the most urgent part of the problem in the most unintrusive way. Even in code, it's just two corners and the extra checks are quite encapsulated, i.e. pretty independent of the rest of the code.

(In reply to Mark Hepburn from comment #35)

I write typically 80 to 120 emails a day, and reply to many more. When composing, I'm composing to teams for which I have created lists, but I often CC: others who aren't on a team list but need to be considered stakeholders. Thus, I'd say that about 80% of the time I'm including a CC: in an email. ... I create and disseminate corporate policy and can tell you what it is that I would very much like, which is for an option for the CC: field to default to being open without clicking something. I'd also like it to be empty.

Thank you very much Mark for providing this insight into the enterprise needs for this feature: Using CC almost every time, but populated differently per-message, so that auto-CC doesn't fly.

Currently, the product as patched presents a CC: field with my email address populated.

For the avoidance of doubt, you are talking about the status quo, right?
My patch provides for the feature of showing an empty (unpopulated) CC/BCC field by default, customizable for each identity.

Yes, the status quo is that on opening a compose window, the CC: field is open with my email address populated. If I do not choose to CC: myself, then the field is by default not presented at all, and I have to click the option to open it.

My current preference settings are to have BCC: enabled as I always include a copy to myself on all messages. A CC: to myself so I can have the field presented, which I tab to and simply backspace my name out of and replace with whomever I want to include. I find this preferable to using the mouse as it is all keyboard strokes. Simply faster by any measure even though it is more strokes but I type 75 WPM so it's just a preference.

If the settings could be set per user or per identity to allow the CC: window to be presented - and empty - as a default, then a simple tab through the fields would be very fast for any user who uses tabs. A mouse user would be unaffected. I think you'd find that the tab users are your more demanding "power users" who use keyboard shortcuts as I do, and generate more email. Of course that is just anecdotal.

Thanks again!

Mark

(In reply to Mark Hepburn from comment #38)

Yes, the status quo is that on opening a compose window, the CC: field is open with my email address populated. If I do not choose to CC: myself, then the field is by default not presented at all, and I have to click the option to open it.

Understood. That's an extra targeted click every time which disrupts the high-efficiency keyboard workflow, where a simple Enter or Tab could suffice.

My current preference settings are to have BCC: enabled as I always include a copy to myself on all messages. A CC: to myself so I can have the field presented, which I tab to and simply backspace my name out of and replace with whomever I want to include. I find this preferable to using the mouse as it is all keyboard strokes. Simply faster by any measure even though it is more strokes but I type 75 WPM so it's just a preference.

So to reiterate, here's an enterprise power user who even prefers to do extra keystrokes just to avoid the hassles of showing the field with a mouse click or counterintuitive backwards keyboard navigation to the button.

If the settings could be set per user or per identity to allow the CC: window to be presented - and empty - as a default, then a simple tab through the fields would be very fast for any user who uses tabs. A mouse user would be unaffected. I think you'd find that the tab users are your more demanding "power users" who use keyboard shortcuts as I do, and generate more email. Of course that is just anecdotal.

+1. I think that's typical.

Sorry for for adding yet another comment, but I'd like to add some points on the long-term maintenance cost of code.

• Every line of code comes with a cost, that's trivial. As stated above, cost-benefit ratio matters, and "customer service" matters even more.
• Please note that much of my code is comments, e.g. in MsgComposeCommands.js, 11 of 33 lines added are comments, that's 33% comments, and the actual code is only 22 lines in spite of the spacy formatting which we are using (where just 1 bracket often ends up on its own line). And it's two identical blocks of code, so the mental processing burden is only around 11 lines.
• The "maintenance cost" of well-documented quality code in a block is MUCH lower than undocumented spaghetti code. Give my code to a random developer in 10 years, and he'll still know exactly what is going on.

Hi everybody, as I posted the bug 1673580 (which is a duplicate of this one) let me tell you few points of view from a user and not programmer.

As Firefox so Thunderbird were used by me and also a lot of other people I think, for the adaptability (settings, configs, addons). Last few years this is a huge problem in my opinion. More changes... less options. 1,5 year ago i switched from Firefox to Waterfox as the new FF Quantum disabled so many awesome addons I used for everyday work (and after 1,5 years the adaptability of new FF is still not on the level, the previous FF was). Now when i have updated to the new TB (I disabled the updates for months as my experience with the FF switch was horrible) I was faced with the same issue. I understand you want to move the products forward, but such a huge changes make people who use addons and a stable way of work frustrated - i had to spend really few days with setting the upgraded TB to some workable state. OK, I made it in some way (thank God the Send later addon exists now in pre-release state).
But let me tell you about this bug. I become really frustrated if I have by EACH email I write (and i write about 50-100 per day) to move my hands from the keyboard, touch the mouse, move it to the Cc and than sometimes one more time to Bcc icon (rather not speaking about one more click to Return-receipt-to which i need if i want to use send later addon, which i use also pretty often) opposite to simple TAB button switch to the next row as i worked in previous TB. I am not o programmer, but some simple "PIN to" icon if you activate the other rows (from Cc to Delivery-notification-to) or some config settings as described above should be still available, if you make such a big change (hiding something which was present). I use Mozilla products also in my small business and facing this kind of problems, solving which cost a lot of time which I can not spend with my business or family is really frustrated.... it is like you would work for years on a Windows machine and next day you would get a Linux machine. Yes, you can probably write some document and send some email, but if you need to do something more specific you will face problems which cost you hours of looking for solution. Please understand, users do not have your knowledge and each change cause a/lost of functionality for them or b/ hours of looking the web for a solution.
And deciding in which way should people use the email client - this is not the Mozilla with its user-friendly orientation as it was... If software has some ability, you should not deny it, this is not a progress... Hiding something should NEVER be denying it. This makes at least some people frustrated...

You do not need to react to my post, I only wanted you to read also some user point of view.

But at least let me thank all of you for the work you are doing and hope, the days of huge changes are behind us and Mozilla products will come back to the user friendly adaptability which was the difference to other software.

Some users in Support Forum are requesting the ability to auto display the Cc and/ or Bcc fields in the 'Write' window.
They use them a lot in a business or hobby group environment where people need to be copied in and that person maynot be the same each time.

Manually selecting Cc and/or Bcc everytime in a Write window is a real time waster and very annoying.
This requirement has become necessary in version 78* due to Addon extensions no longer functioning.

Currently:
If in Account Settings > Copies & Folders' you select the Cc and Bcc checkboxes. The account email address is auto completed in both those fields.
So you need to manually remove them because sending a CC and bcc to your self is not required.
Despite removing the email addess so field is blank, on opening a compose window, the CC: field is open with my email address populated and there is no Bcc field.
Neither is correct.

It would be an intuitive means of setting an auto Cc and/or Bcc in a Write message based on account preference.

An alternative would be to set up default via Options > composition, but this would effect all accounts which may not be desirable.

Whether this is something you (not any particular person) personally use yourself is not something for debate, the point is that it is a very necessary requirement in many environments and needs to be implemented as an option.

I support Thomas D suggestion to get something working by using the 'Account Settings' > 'Copies & Folders' option where Cc and Bcc are selected and blank, they should auto generate the respective Cc and Bcc fields in a Write message where the From is that account.

Since I've been bombarded daily by messages from users that need this feature, there it is.
With this patch, two new prefs are added per-identity in the Composition & Addressing section.

I'm not taking over the bug as I think this patch needs some improvements related to properly hiding and revealing the fields when replying or switching identities or the height of the header area not updating properly.
Some initial work for very simple scenarios has been covered.
I'm relying on the expertise of Thomas to improve this.

Magnus, let me know if you think this is sustainable solution, but I think we should implement it as this seems to be a must-have for many users.

Request 'always show CC / BCC field in compose window' duplicate bug 1674794

As more people are now getting the auto update to 78.4.0, the Support Forum inevitably starts to report issues and not being able to keep a Cc and/or Bcc field automatically open and the inability to use addons that may have assisted in the past is causing grief.
https://support.mozilla.org/en-US/questions/1310396

I'd like to point out this is not relevant to 68 -> 78. Yes, things changed, but 68 did NOT have a Cc/Bcc automatically showing. It only had "To:". Selecting to use a Cc/Bcc was different.

People had previously been able to use addons for years eg: Use BCC Instead C, which are no longer available thus appearing to remove functionality many had used for a long time. Perhaps I should have been mentioned this, however it is mentioned in the Support Forum link. Maybe it seems more obvious to me why users are making this request because I spend alot of my time helping in the Support Forum, a side benefit of which allows me to understand the users perspective.
For anyone in a work environment who needs to Cc alot, it really is a necessity to aid workflow.
Being forced to use the Account Settings to get an auto Cc or Bcc by using your own email address is really a bad design. Yes, you can leave it in the Cc/Bcc and continue entering required email addresses, but to strive to improve the design is how things move forward.
This bug is a request for enhancement.

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

I'd like to point out this is not relevant to 68 -> 78. Yes, things changed, but 68 did NOT have a Cc/Bcc automatically showing. It only had "To:". Selecting to use a Cc/Bcc was different.

It is true that this functionality was not necessarily available in previous releases, but I believe it is also true that one could tab through to choose both CC: and BCC: fields (or so I recall, but I'm pretty old and you get the idea :-D).

Having said that, it's also true that at one time rich text couldn't be viewed in an email, much less a graphic. We've evolved and as new situations arise, I hope that TB will continue to as well. The use case for having the capability (for which I also submitted a request) is clear in the minds of most business users, and not only enterprise level, but mid-size companies as well. My company has about 40 users but we interact all day long among one another and also with large (think 25,000+ desktop clients) customer whom we serve.

The CC: field is a constant go to for us. And because we interact with so many different stakeholders, we can't just create multiple group lists to provide the missing functionality. Often it is an ad hoc group or a temporary need. While I do create lists for a number of ongoing situations, I find that I have to click that CC: button probably 40 to 80 times each work day.

I've changed to including myself in CC: to open the field by default, so I can tab over to it and backspace to delete it. Much faster because I don't have to use a mouse at all.

For me, I would think that the CC: field being open by default would pose few problems from the UI standpoint. Those who use it actively will have access to it, while those who don't can simply ignore it or tab to the Subject line

(In reply to Anje from comment #49)

Being forced to use the Account Settings to get an auto Cc or Bcc by using your own email address is really a bad design. Yes, you can leave it in the Cc/Bcc and continue entering required email addresses, but to strive to improve the design is how things move forward.

And that doesn't even work reliably. When starting to write a new e-mail and then switching from the default sender identity (the identity of the first defined account in the account manager) to one of my other sender identities TB 78.4.0 somewhat randomly and more often than not just ignores the entries for the Bcc and Cc defined in the account manager.

(In reply to il_falco from comment #51)

When starting to write a new e-mail and then switching from the default sender identity (the identity of the first defined account in the account manager) to one of my other sender identities TB 78.4.0 somewhat randomly and more often than not just ignores the entries for the Bcc and Cc defined in the account manager.

Please report a separate bug for that, and reference the bug report number here.

Getting requests from the support Forum.
https://support.mozilla.org/en-US/questions/1313234

Any idea when this type of functionality is likely to be available ? Mainly so I can advise all those who ask ?

There's a WIP patch I uploaded that it's in queue for review.
If approved, it'll most likely be available in beta 84 or 85, but I doubt it'll be uplifted to 78 due to string changes.

In https://www.thunderbird.net/en-US/thunderbird/78.4.0/releasenotes/ it says tell us what you think without giving the ability to at the linked page.
The "new" layout sucks and discourages use of Mozilla Thunderbird. I use CC a lot, as well as BCC occasionally. Always and for every mail, I now must add those fields manually from the space besides the To-field...?
There is no add-on (yet) to resemble the previous logic, so I will now actively look at alternatives to Thunderbird. As much as a change of client sucks, this is one of the changes done by developers not thinking about usability but only about design?
And then to add more than one, you shall separate them with semicolons? Back to the 90s (You Got Mail)?
This way, Thunderbird is no longer an "intuitive" alternative. So after Firefox, now Thunderbird leaves my computer and in turn the list of programs I provide family&friends support for.
Also for existing users, the "changes" came without much of a help on how to adjust.

Your message goes against the CPG: https://www.mozilla.org/en-US/about/governance/policies/participation/
If you want to keep participating in the discussion, I'd like to politely ask you to be more respectful and write constructive criticism, and avoid unhelpful emotional responses.

In https://www.thunderbird.net/en-US/thunderbird/78.4.0/releasenotes/ it says tell us what you think without giving the ability to at the linked page.

Thanks, I will add a note to the website repo in order to implement a call to action at the end of the release notes.

The "new" layout sucks and discourages use of Mozilla Thunderbird.

How? This feedback is not very helpful. Also, this is a bug specific for the Cc and Bcc fields, so if you have other comments or requests, please write in the support forum or open dedicated bugs.

I use CC a lot, as well as BCC occasionally. Always and for every mail, I now must add those fields manually from the space besides the To-field...?

Those are 1 click away. Is it really that disruptive?
Nonetheless, in this bug there are a couple of patches under review to add an option to always have those fields visible. Please, read the previous messages and the solution we're considering.

As much as a change of client sucks, this is one of the changes done by developers not thinking about usability but only about design?

Did you try using the new compose area? What usability issues are you experiencing? Despite your personal beliefs, the new compose area improves a lot usability and accessibility compared to 68. Now, if you're talking about muscle memory, that's another story.

And then to add more than one, you shall separate them with semicolons? Back to the 90s (You Got Mail)?

Do you know that you can let the pill be created by also pressing ENTER, COMMA, TAB, or by simply moving away from the field (eg. going on the subject line or body). Did you try to use it?

Also for existing users, the "changes" came without much of a help on how to adjust.

Not true, as we wrote a detailed guide about it since early betas: https://support.mozilla.org/en-US/kb/addressing-email

As I said, please read the context of the bug and be sure to read the previous messages to only write constructive and useful messages that are part of the core topic of the bug.

Thanks.

For the completeness of the offical record, wearing my documentation staff hat (but then let's really continue that discussion elsewhere, e.g. on support.mozilla.org/thunderbird or Thunderbird UX <ux---at---discuss.thunderbird.net>):

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

I use CC a lot, as well as BCC occasionally. Always and for every mail, I now must add those fields manually from the space besides the To-field...?

Those are 1 click away. Is it really that disruptive?

Well, it is disruptive if you need it for dozens of messages every day, hence this bug. I think keyboard users are most affected, because Shift+Tab,Tab backwards when you want to add recipients forwards really isn't so cool or intuitive (although we have carefully chosen the placement of those disclosure buttons after weighing lots of pros and cons).

Until then, you can also open contacts sidebar (F9), search recipients there, select multiple recipients, and use "Add to CC/BCC" buttons respectively via mouse or keyboard, which will open the (B)CC field automatically and add them. You can even select recipient(s) from To:, right-click selection, "Move-to-CC/BCC".

Did you try using the new compose area? What usability issues are you experiencing? Despite your personal beliefs, the new compose area improves a lot usability and accessibility compared to 68. Now, if you're talking about muscle memory, that's another story.

Ironically, as for adding multiple recipients of the same type, exactly following muscle memory would get it right: type recipient, press Enter (once only!), type another recipient, press Enter (once only!). Two times Enter will get you to the next addressing row or subject (as in TB 68, only that now each row holds multiple recipients). It's the legacy user expectation that the first Enter should get them to another row of the same type which makes them press Enter twice and shoot themselves in the foot. Yeah, still muscle-memory, sort of... Fortunately, muscle-memory can be re-trained, and the UX benefits delivered are well worth it - says me as an avid keyboard user!

And then to add more than one, you shall separate them with semicolons? Back to the 90s (You Got Mail)?

Semicolon is strongly discouraged, and has never been officially recommended. Accepted for pasting, press Enter to convert to recipient items aka pills.

Do you know that you can let the pill be created by also pressing ENTER, COMMA, TAB, or by simply moving away from the field (eg. going on the subject line or body). Did you try to use it?

Also for existing users, the "changes" came without much of a help on how to adjust.

I guess we could still make that easier to find, but it's not easy to link up everything everywhere... Sorry hey!

Not true, as we wrote a detailed guide about it since early betas: https://support.mozilla.org/en-US/kb/addressing-email

And another one, here, which has also been available for quite a while, and more recently, linked in official in-product release notes:
Help > About TB > Release Notes > "For more on all of the new features in Thunderbird 78, see New in Thunderbird 78.0."

https://support.mozilla.org/en-US/kb/new-thunderbird-78#w_new-addressing-area

Now that you know, please spread the word! Better still, you may want to assist with translating these articles!

As a follow-up to the previous post, I would just like to mention that triggering the side bar to search for recipients is even more clumsy than having to mouse click to open the cc field or the BCC field. For keyboard users who often copy people frequently it’s much easier to just type the names and email addresses. My preference would be complete keyboard use and eschew the mouse all together.

I downgraded to 78 from the beta, hoping that the current development of patches would be available so you can say I’m quite eager for the change. LOL

Comment on attachment 9178125 [details] [diff] [review]
1616514_acceptEmptyAutoCcBcc.diff

In the interest of TB 78 reputation and user acceptance, I'm proposing to fast-track this much-demanded feature using this patch, which can easily be uplifted into TB 78: no new prefs, no c++ code, no translations.

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

[snip]
I'm worried that we're not delivering this important and much-demanded
feature to users as fast as possible. Lots of users have identified this as
a painpoint of TB 78, so fast delivery will be in our best interest.
I like Paenglab's idea in comment 28 of landing my patch attachment 9178125 [details] [diff] [review]
as a fast fix for TB 78 and gain time to craft a more elaborate fix.
Fwiw, my patch does not need new prefs, c++ code or translations and I
believe it was covering all CC/BCC scenarios at a very low cost of
implementation. I think it's easily maintainable even when we add a more
elaborate solution later.

I've laid out my ideas for a more comprehensive and versatile, but still low-cost solution in the first part of comment 59.

This could be somewhat mitigated (not addressed!) by Bug 1667692 - Explore implementing keyboard shortcuts to show and focus important address rows (To, CC, BCC): Ctrl+Shift+T, Ctrl+Shift+C, Ctrl+Shift+B (like gmail). However, implementing those keyboard shortcuts isn't trivial either wrt existing keyboard shortcuts and future sustainability.

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

**I'm worried that we're not delivering this important and much-demanded
feature to users as fast as possible.

Thomas, any update on status and timeframe to implement a long term solution such as those you have suggested?

As an adjunct to this functionality, see also bug 1687117.

Magnus, I think the feature of having a per-accoutn preference to always show the Cc or Bcc field is important.
We've seen the duplicate and similar requests users are asking, and the messages in the support forum.

Do you have time to review the patch I uploaded? I tested it and it still applies cleanly.
I think we should consider it, definitely not for 78, but would be nice to have something like this landing on beta and get through a normal testing cycle.

Comment on attachment 9184675 [details] [diff] [review]
1616514-permanent-fields.diff

Sorry for the delay. I guess if we really want to support it, we can do it with the current checkbox in the UI, even if it's not as discoverable.

Unbitrotted and revised patch - let's do this!

• This patch adds a new string which adjusts the existing placeholder text to make this feature discoverable. It's my first time to add a new Fluent file, hope I got that right.
• The placeholder text of the input is replicated in a title attribute for cases where the window might be too small to display all of the placeholder text, and to keep the placeholder information available via the title even when the address list already has addresses.
• From my tests, gMsgCompose.compFields.cc is always "" (empty string), even if it does not contain addresses. So I am showing the empty row inside the existing condition if (typeof msgCompFields.cc == "string") {. As a caveat, in spite of trying pretty hard, I was unable to verify where exactly gMsgCompose.compFields.cc gets initialized to empty string.

Here's a screenshot of how it works and looks (with patch of attachment 9208068 [details] [diff] [review] applied) to always show Cc/Bcc address row by default for a given identity - check the checkbox and just leave the addresses input blank.

So with the strings change we're not gonna uplift this to 78, right?
We're potentially a couple of months away from the next ESR and we might simply let this patch run the release train.

Placeholders aren't suppose to contain instructions (but examples). But the suggestion now is wrong: to always show the cc you tick the box and leave blank. I wouldn't really add any verbiage about it.

I'm sorry to walk back on this, but I really doubt this is an acceptable solution.

I originally agreed with using the checkboxes last year as a quick 78 fix without the necessity of adding strings.
But at this point, with a few months away from the next ESR, we should aim for a better and more solid implementation.

Using those checkboxes is not discoverable, being in a section that is out of context from what we're trying to achieve, and implementing a string change that doesn't make much sense.

What's wrong with my proposal in attachment 9184675 [details] [diff] [review]?
Do we want to avoid adding those fields to the C code? Any technical reason I'm missing?
Adding those options in the Composition & Addressing makes way more sense for context and discoverability.

I hope I'm not sounding too harsh, that's not my intention, and I apologize for any delay I'm causing, but we should aim for an optimal and long standing solution to implement a preference that many users requested.

I think it just adds complexity much more than is warranted. I've proposed we just do the per-window approach instead in bug 1667692.
The whole concept of identity based options is not likely discoverable at all except for by a 5% power user group.

I appreciate all people working on Mozilla products (I am only a user) and do not want to be misunderstand because I am thankful for all your work, but it would be really helpful to implement any working solution first and may be then discuss about further better improvements...Discussion on this issue last ONE YEAR... On one hand I understand you are looking for a long term solution, but on the other hand people using Cc and Bcc on everyday work (like me) feel very comfortless using TB and clicking Cc and Bcc icons multiple times a day like fools for mentioned one year...:( Endless discussions are sometimes contra-productive. As I have understand there is a working solution, PLEASE implement it. I am sure, people who need it will be able to understand, how to use the proposed solution... Many thanks.

Any updates on this?
Thomas, do you have time to take this back and apply the edits we discussed?
This should definitely land before the next ESR.

(In reply to Alessandro Castellani [:aleca] from comment #75)

Any updates on this?
Thomas, do you have time to take this back and apply the edits we discussed?
This should definitely land before the next ESR.

Yes, will file a new patch soonest.

Updated patch with edits as discussed.
Improved the wording of the new <description/>.
Let's do this!

(In reply to Alessandro Castellani [:aleca] from comment #78)

Review of attachment 9220777 [details] [diff] [review]

Perfect review with a keen eye for the detail, thank you!
This patch addresses all nits of comment 78.

Trying to eliminate the <textbox> notion has resulted in a more aggressive rewrite of the existing functions according to our "generic event handlers" best practice. I also like shrinking and disentangling code.

• Code cleanup; use generic event handler functions and eliminate duplication.
• Safeguard against whitespace-padding of the auto-Cc/Bcc address list to ensure its visibility in the input field; now that we allow empty input, you might shoot yourself in the foot with an unfortunate copy/paste, or someone might think of exploiting that. I'm only preventing the most basic cases of unwanted whitespace-padding (using traditional whitespace characters), so it's probably more of a neat string thing...

(In reply to Alessandro Castellani [:aleca] from comment #80)

Review of attachment 9221384 [details] [diff] [review] ⧉[details] [diff] [review]:
A lot of our users will be very happy about this feature.

+1!!!

Just a few small nits to fix.

All fixed, thanks.

+account-prefs-show-address-row-description =
+    Leave the address field blank to always show the address row when starting a new message.

nit: put this inline as we don't go to another line for elements that don't
have attributes. Also this might make our fluent linter fail, probably.

Odd!

+ * @param {string} inputId - the ID of an Auto-Cc/Bcc text input element

nit: All params description should start with an uppercase and end with a
period. Same thing for all other comments.

Still struggling to convince my brain of this ungrammatical syntax, but looking at https://jsdoc.app/tags-param.html, apparently that's the standard.

+  let input =
+    checkbox.id == "identity.doCc"
+      ? document.getElementById("identity.doCcList")
+      : document.getElementById("identity.doBccList");

Since we rely on the ID here, maybe we could do something like this to save
a condition:
let input = document.getElementById(${checkbox.id}List);

While this is boldly brilliant to shrink the code, it also obfuscates the real IDs used: It will no longer be possible to machine-search for all spots in code where the ID is used, which looks like a maintenance disadvantage. I couldn't resist the ingenuity of the template literal, but I've included the real IDs in a comment for searchability.

This addresses the review nits of comment 80 exactly as proposed (see my comment 81).

Comment on attachment 9221608 [details] [diff] [review]
1616514_acceptEmptyAutoCcBcc.diff

r=aleca from comment 80 (all nits fixed).

Why are you moving these to fluent?

Mhh...I think I suggested this in a past review because we were changing the text.
If the text is identical I guess we can avoid changing it.

Also, placeholders should really be examples (the old code is wrong).

Should we maybe write something like email1@example.com, email2@example.com, etc.?

Yes

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

Review of attachment 9221608 [details] [diff] [review] ⧉[details] [diff] [review]:
::: mail/locales/en-US/messenger/preferences/am-copies.ftl

+account-prefs-auto-cc-addresses =
+    .placeholder = Separate addresses with commas

Why are you moving these to fluent?
Also, placeholders should really be examples (the old code is wrong).

You are right, moving the placeholder strings to fluent is no longer needed, as they are not relevant for this bug. I have removed this peripheral change from the patch. If there's something wrong with the pre-existing placeholders, let's sort that out in a dedicated bug to avoid more delays here.

(In reply to Alessandro Castellani [:aleca] from comment #80)

Review of attachment 9221384 [details] [diff] [review] ⧉[details] [diff] [review]:
This is good, thanks for taking care of this.
A lot of our users will be very happy about this feature.

+1. Many enterprise users have been eagerly awaiting this ux-efficiency fix for more than a year now.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/a070c087756d
Allow auto-showing empty CC/BCC address row for compositions via identity's doCc/doBcc prefs. r=aleca

I suspect this has broken comm/mail/test/browser/account/browser_manageIdentities.js but I need to rebuild to verify

Ah, damn.
Good find. I'll take care of fixing the test.

Found the problem.
Missing fluent string as the am-copies.inc.xhtml is used also in a subdialog.
The issue should be fixed, but let's wait for a green try-run before setting the check-in flag.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=4b4102445ef592727d7e067f7913cce2c6524bb2

(In reply to Alessandro Castellani [:aleca] from comment #92)

The issue should be fixed, but let's wait for a green try-run before setting the check-in flag.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=4b4102445ef592727d7e067f7913cce2c6524bb2

I'm not seeing any failures related to this bug, do you?

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/68bcf2f7565a
Allow auto-showing empty CC/BCC address row for compositions via identity's doCc/doBcc prefs. r=aleca

This has been closed without anyone providing instructions on how to always show the CC field. I can't see any options anywhere to do it. Please can you explain what we need to do?
Thanks.

(In reply to Brian S. Craigie from comment #95)

This has been closed without anyone providing instructions on how to always show the CC field. I can't see any options anywhere to do it. Please can you explain what we need to do?
Thanks.

As indicated in earlier comment, this new feature won't be made available in 78.x branch (current stable), but has been pushed already in the beta channel version 90.x branch... so will be available soon in the next stable version of TB.

In 90+ version the feature remain available in the Account Settings > Manage Identities > Edit > Copies & Folders just tick the box in front of Cc or Bcc. This is a per Identity settings, to keep in mind!

In 78.x, you should be able just to tick the box and preset an email address, yours for example, in the Cc or Bcc field in the same settings location, to trigger the automatic display of field when composing new email... this email address will appear as well but you can easily remove it when composing the email. This requirement shall disappear once upgraded to the next stable version of TB in the future.

(In reply to Brian S. Craigie from comment #95)

This has been closed without anyone providing instructions on how to always show the CC field.

Well, Alex announced this feature with explanation on the tb-ux mailing list on 19-05-2021

My documentation is here:
https://support.mozilla.org/en-US/kb/new-thunderbird-91#w_efficiency-where-you-need-it-most-improved-addressing-area-for-new-messages