Following with interest. I was a user of MRC, but had to drop it as it is currently incompatible with Cardbook (which provides two way integration with could address books, like google's).

MRC with the fix to allow these address books (https://github.com/michelRenon/mrc_compose/issues/35 ) would be a massive improvement to Thunderbird.

This bug is long overdue.
Here's a mockup I did for the redesign of the address area in the compose dialog.
attachment 9052074 [details]

(adding back the old summary for findability)

All right, here's a first and super broken patch as a proof of concept for this new implementation.
I'm asking early feedback before going to deep.

This is just a test patch with some early work, almost everything is broken and not functional at all, so, be careful. These are the things I did and looking for feedback.

• Only 1 autocomplete input, no duplication of rows (the CC, BCC, etc, will have their own fields).
• On enter or autocomplete select, the value gets converted into a custom element.
• The new CE is a blatant copy of the email address field in the Message Header. For now is super broken, but the objective is to have the same features of the Message Header, like adding an address to the Address Book, the same context menu, etc.
• Invalid emails or not matching the address book will be highlighted in red.
• The field can handle multiple addresses at once pasted in, separated via comma or semicolon.
• After every enter, the focus stays on the input field to allow a continuous typing experience.
• I also did a bit of dark mode styling, but nothing too crazy.

That's is so far, pretty barebone initial patch.
The UI is pretty ugly right now and nothing really works, but as I said, this is just for an early evaluation.

What do you guys think about the approach from a code POV?
Does it look decent so far?
Is this a good direction?

Uploading a quick screencap to showcase it.

As far as I can see from the attached video sample, this is really awesome!
The interface gives a good experience, expecially to unexperienced users.
Good job 👍

Please keep us updated on your progress; I'm ready to test it when you have a testable version.

Result and video are great... well done! Very promising...

Perhaps I would suggest to set the recipient name in bold perhaps so to create some sort of visual "separation" or "distinction" (both between name and address and between Pills) without adding any extra spaces... this would help to review entries visually... especially when numerous... if that make any sense...

Would it now also be possible to copy and paste multiple addresses from a draft email to a new one at once?

Other ideas for later... if you would consider...

What about coloring Pills other than grey to see them better at least?

One color per Addressbook perhaps? Or at leat to distinguish those coming from Addressbook, Auto-Collected and New (maybe not red as this color in associated with error)?

When typing recipient not selected from auto-completion (e.g test@test.com), one could imagine that pressing space bar any time after @ would act as comma, semi-colon or enter and convert entered data into a Pills (if valid or tolerable mistake) which may be even easier and more natural way to separate recipients perhaps... in addition of other options available...

Also only converted and valid "name <address>" shall be converted in Pills and saved in auto-completion (upon sending? or conversion into Pills?) for new recipient... faulty once shall not be converted, saved or usable (or at own risk?)... a warning would raise upon
conversion/validation... but still allowing end-user to correct or continue at his own "risk" ;-)

This is looking good overall, a nice and promising start on a valuable feature! I have a few thoughts.

Glancing over the code I noticed two places where the focus shifts to the subject line. Ideally there would be only one place where that happens. Should be do-able.

As a user I share the concern expressed above about not being able to copy a group of addresses that have been entered. (It's one of my frustrations with the current one-address-per-row UI.) It looks like pasting a group of addresses in would work (right?), but copying them back out looks like a more difficult problem -- if we want to be able to do that and have the pill functionality.

If we can't support selecting and copying (and deleting?) groups of pills, then we might consider offering other options, like maybe a button to "copy all to clipboard" or maybe a toggle that switches the view between "pill view" and "plain text view". Some users might prefer the plain text option. If a plain text view is something we want to offer, then it might make sense by starting with it (simpler) and then adding the pill view.

I suppose you could let backspace delete the previous pill when there's no text in the input field.
I assume it will be possible to edit an address after it has become a pill.

Finally, I have some thoughts about our use of custom elements that are a broader / another topic. I'll save that for an email or something else that's not this bug. (We're about to hit triple digit comments on this bug, so might be worth making it a meta bug at some point.)

Perhaps I would suggest to set the recipient name in bold perhaps so to create some sort of visual "separation" or "distinction"

That's a good point, and really easy to implement. I'll see how it looks at a later stage, when thorough UI polish is needed.

Would it now also be possible to copy and paste multiple addresses from a draft email to a new one at once?

Yes. It will be possible to select all the pills to copy and paste them into another draft email.

What about coloring Pills other than grey to see them better at least?
One color per Addressbook perhaps? Or at leat to distinguish those coming from Addressbook, Auto-Collected and New (maybe not red as this color in associated with error)?

I'll explore better colouring at a later stage, but I'm not excluding these suggestions, thanks.

Also only converted and valid "name <address>" shall be converted in Pills and saved in auto-completion (upon sending? or conversion into Pills?) for new recipient... faulty once shall not be converted, saved or usable (or at own risk?)... a warning would raise upon
conversion/validation... but still allowing end-user to correct or continue at his own "risk" ;-)

The pill won't be created unless there's a valid email address in the string (I'm coding this right now).
Fixing a mistaken "saved in auto-completion" action is something we should tackle in a separated bug.

Maybe it's only me but for me it looks a bit strange when the pills aren't in the textbox and the textbox moves to the right.

Yeah, that's just temporary as proof of concept. The final implementation won't show a separated textbox but rather the entire row will be clickable to add more addresses.

Tabbing doesn't focus the pills.

Yes, that's something I'll fix once tackling the keyboard navigation of these elements.

Also do Mailing lists get the warning class.

Yup, I still working on that :D

As a user I share the concern expressed above about not being able to copy a group of addresses that have been entered. (It's one of my frustrations with the current one-address-per-row UI.) It looks like pasting a group of addresses in would work (right?), but copying them back out looks like a more difficult problem -- if we want to be able to do that and have the pill functionality.

Copy and pasting multiple pills at once will be possible.

If we can't support selecting and copying (and deleting?) groups of pills, then we might consider offering other options...

All these things will be available and will emulate the same behaviour of dealing with a simple text string.

I suppose you could let backspace delete the previous pill when there's no text in the input field.

Yes

I assume it will be possible to edit an address after it has become a pill.

And yes

Thank you all for the feedback, I'll keep working and upload another WIP patche once I reach a good state.

Strongly disagree with this initiative as now stated; and - this is a key aspect of Thunderbird UI which merits a wider surveying of users IMHO.

The opening comment says that one-row-per-address is

OK for 1-3 addresses, but with more it is a real pain.

Not it isn't - in itself. It has issues which may need to be addressed - but going many-address-per-line is trading one set of problems for another. I will elaborate below, based on Olaf's list of arguments. But the main point is that it is difficult and inconvenient to search through multiple lines with variable number of recipients each of varying length and possibly different languages. The fact that Thunderbird does not make you do that (when writing email at least) - is a benefit of Thunderbird over, say, MS Outlook and Evolution. Don't take it away please

Almost every other software supports putting addresses in comma separated list.

And so does Thunderbird. You can type that in or copy-paste it and it'll get adjusted to the one-address-per-line view. If you want to see all the addresses narrowly-spaced together - that could be a feature I suppose, but not replacing what we have now.

Olaf presented several arguments against the current UI approach; let me address them.

1. Habits - if people use other e-mail clients they expect that things work in similar way - please don't classify this simply as aesthetics.

The important habits are for Thunderbird users, not for MS Outlook users; and immitating MS Outlook is not a principle to go by. Also note that when writing formal letters, we typically have one recipient per line - that is the actual habit to uphold.

2. If you have more than 4 recipients you need to scroll - this is what makes me personally unhappy, in outlook you can enter more than 15 addresses (depending on address length:) per one recipient type (To, Cc, Bcc) before you need to scroll (the widget expands up to 4 rows before adding scrollbar).

When you have more than 20 or 30 recipients, you would need to scroll with multiple addresses per line. Plus, the non-scrolling search becomes difficult faster.

It is much easier if you can see all the recipients at a glance.

No. It would be easier if we could see them all aligned. But on a single line - we don't really see them at a glance. Unless there are few of them, in which case we usually see them at a glance as things stand already.

You won't miss any person to send, and what is more important - you won't send to a person that shouldn't get the mail :)

You very well might - since it's easier to miss people in non-aligned layout. Also, with many recipients - you need to scroll anyway, and scrolling is much easier when there's alignment.

3. If you put several entries in "To" and then you change your mind and want to put some of them in "Cc" or "Bcc" it is easier to copy and paste than to change every "To,CC,Bcc" combo.

But if you move a person from "To" to "CC" it is more difficult, since instead of just two clicks - or even a single click, see: https://bugzilla.mozilla.org/show_bug.cgi?id=251917

4. If you want to remove some addresses you need to select every one separately and delete.

That is not inherent to a one-address-per-line layout. This can, and should, be changed. I'm pretty sure there's a bug page about that.

BTW. there is no way to delete unused fields, it is possible to delete only addresses.

You don't need to "delete unused fields"; there are infinitely many unused rows at the bottom of the recipient list.

5. If you send several messages to the same group of people (or a large portion of addresses is the same - eg. all addresses in CC). With "multi address" fields (like in Evo, Outlook) you can just select and do a copy/paste. In Thunderbird it is impossible.

This is just the combination of the previous issue and the next issue.

To make this even harder, in Thunderbird the text in message header pane cannot be selected, so you can't select addresses from a message and put in address fields. I'll fill separate bug for it anyway.

Indeed, that should be addressed - we should be able to copy multiple recipients when reading messages as well. For now it's possible by viewing the source and copying the text from there... :-(

A few final points:

• One line/field per recipient means you can order your recipients either by category (To/CC/BCC), but also in other ways (e.g. alphabetically), while one line per category forces an ordering.
• I would have liked to see better real-estate use by making it possible for users to indicate they want to add recipients in another column, splitting the recipient list section of composition window vertically (but not right from the get-go so it doesn't look like a bingo card).
• A one-line-per-category preview of the recipients would also be nice, but not as the only way to enter them.
• aleca - putting aside the fact that I don't like the basic notion, it seems nicely implemented. I don't mean to disparage your great work!

100 comments....yay...
Thanks for your feedback Eyal, but it's missing completely the scope of this patch.

Strongly disagree with this initiative as now stated; and - this is a key aspect of Thunderbird UI which merits a wider surveying of users IMHO.

The proposed UI with a thorough explanation of the various usability features was released here: https://thunderbird.topicbox.com/groups/ux/T37151b06e9361fac/work-started-on-redesign-recipients-address-fields-to-cc-bcc-etc

It was reviewed and approved by the core team and the technical director, and the exploration of this solution was initially introduced 7 months ago in bug 1535503.

All your points and issues are mostly related to the way you're personally used to use the compose message, how you feel comfortable, and the workarounds you learned with time to overcome some issues.
Those are not an indication of good usability and intuitive UI.

The proposed solution introduces many usability improvements, and helps streamlining the UI for multiple scenarios, while the current implementation comes with too many "IFs" and "BUTs", and it doesn't scale gracefully.

I'm sure you'll have many further points, so please keep writing in the topicbox thread and let's limit this bug to code related feedback.
Thanks.

All right, this is starting to get into a pretty good shape.
Here's the full list of what's working:

• Pasting multiple addresses will be converted into pills.
• Pills have focus.
• Double Click or hit Enter on a Pill turns it back into an editable autocomplete input.
• Hitting Enter after editing a pill will update the values and switch back to a pill.
• Hitting Escape while editing a pill will revert to the previous value.
• Backspace from the main autocomplete input selects the last pill.
• Delete or Backspace while a pill is focused deletes it.
• Navigate all the pills with Tab and Shift+Tab.
• Warning colour if an address is valid but not in the address book.
• Error colour if an address is not valid.

What's missing

• Add the other rows through links.
• Links will be populated based on user settings (Reply-To, Followup-To, etc).
• Ability to collapse/expand long list of pills.
• Select multiple pills at once with the usual various shortcuts.
• Drag&Drop one or multiple pills within the same container to reorder.
• Drag&Drop one or multiple pills between various containers.

More things to code

• Update all the tests
• Generate pills when forwarding/editing an email
• Enable context menus for the pills like in the email header.

I'm sure I'm missing a million of other things, but slowly, step by step, this is getting pretty.

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

• Backspace from the main autocomplete input selects the last pill.

Hitting Backspace in such situation shall delete the last pill (1) not select it... pressing left arrow (or shift+tab) instead would select it...

That would seems a more natural and expected behaviour from Backspace key...

Alternatively (or in addition) if it was a pill just converted, hitting Backspace shall move back the pill in edit mode (2)... with the pointer set after last character... it would act like erasing last space comma or semi-colon that triggered pills conversion... but only if it was just last edited/converted... otherwise behaviour (1) may prevail...

Just a thought...

It is great to see improvement in this bug. I'd strongly recommend installing MRC Compose for comparison. Features of MRC Compose that help a lot in "more than one address per line" mode:

• Default text that informs users of how to input addresses.
• Ability to show/hide CC, BCC, Reply-to and other fields.
• Counter of recipients on the left of the corresponding field (helps to see if one has double paste a very long list of recipients)
• Ability to configure which address books are searched (LDAP is too slow for me, but sometimes I need to enable it)
• Sorting criteria (Popularity!)

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

• Select multiple pills at once with the usual various shortcuts.

It will be useful if keyboard shortcuts will work exactly as if the list of pills were words separated by ",":

At start of a pill:

• backspace: convert the previous pill to text, pressing backspace again will start deleting text
• ctrl-backspace: delete previous pill
• ctrl-del: delete next pill
• left-arrow: convert the previous pill to text and place the cursor under the last letter (in case I did a typo while writing the address)
• ctrl-left-arrow: convert the previous pill to text and place the cursor at the start of the pill
• ctrl-shift-left-arrow: select the previous pill (one should be able to do this several times to select several pills, like selecting several words)

In the middle of the text of a pill:

• home-end: move to start/end of pill
• ctrl-left/right-arrow: move between words (as usual)
• "," close the pill, start a new one

At any point:

• ctrl-home: convert the first pill to text and move the cursor under the first letter.
• ctrl-end: convert the last pill to text and move the cursor under the last letter:
• shift-ctrl-home: select all pills from current position to the first one (thus, end -> shift-home selects all pills, the Ctrl+C/X copies/cuts all addresses, separated by commas)
• shift-ctrl-end: select all pills from the current position to the last one
• Ctrl-Z undo last edit (undo delete pill/s, undo typed pill/s)

I'm sure you get the idea. This is the standard navigation/editing shortcuts, just that pills are treated as whole words unless they are being edited. Otherwise, navigating/editing many addresses will become a pain and all the benefits of having addresses in a single line (like MCR Compose does) will be lost.

(It would be nice to add to the whish-list to have X and contact photos in the pills like these chips here: https://material-ui.com/components/chips/ )

More improvements to the recipient pills.

This updated patch brings lots of accessibility improvements and various fixes.

• You can navigate through the various pills with the arrow keys other than TAB and SHIFT+TAB.
• Added the X icon to delete pills.
• Fixed the email address re-appearing after a pill was created.
• Fixed a couple of conflicts with the autocomplete while editing pills.
• Improved UI and colours between the different states.

I have another WIP patch that adds the various CC, BCC, etc, almost ready to be uploaded, but I need a bit more time to fix a couple of quirks.

And I forgot to write that the text box is taller than the From menulist and the subject text box. Maybe reduce the space above/below the pill to make it less tall.

Thanks all for the positive feedback.
Here are some notes regarding what your wrote.

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

the delete button inside the pill has a uneven border around it. On the right it is wider than top/bottom.

This should be fixed in the upcoming patch, but anyway I'm not super focused on pixel perfection across OSs, so something will definitely look not aligned until the final patch.

when I edit a pill (not easy to find without a context menu :) ) it expands and shifts the following pills to the right.

Fixed in the upcoming patch, the width of the editing area should respect the length of the pill.
I'm also adding a context menu with the "Edit" item. I was also thinking, would be worth considering showing a pencil icon on hover? So the user can click that to edit the address? More discoverable than a double or right click.

(In reply to Paul Morris [:pmorris] from comment #114)

Double-click to edit a pill, then click to put the cursor elsewhere, the pill stays in 'editing mode'. ..Seems like it should exit editing mode when
it loses focus? (Probably just still to do.)

I'm not sure about this as it might be super annoying for the user. Think about the scenario where you're writing an address, and you need to copy it from another window, or maybe you click somewhere else to view another email and confirm the address, and the pill reverts back losing your temporary editing.
Maybe I can implement a condition in which if the email address is valid while losing focus, the pill reverts back, but if it's not, it remains in edit mode.

When adding addresses, the cursor goes to the next line before you expect it to. And when resizing the window the height of the "TO" field moves from one to two lines where you don't expect it. Would it work to shrink the width of the text input element to avoid these things?

This is an annoying limitation I'm not sure how to overcome as a wider input is necessary for the autocomplete panel. That panel is as wide as the input field, so we can't shrink it down too much otherwise the autocomplete list can get unreadable.

Might not be worth it, at least in the first release of this, but users might want to be able to enter new addresses between existing pills.

That'd be nice, but I'm not sure it's possible with the current autocomplete field. Maybe for the future.

Would be a good idea to develop this behind a temporary pref, so we could go ahead and land code incrementally as we go rather than all at once? Then when it's ready, turn it on?

I'm not against this, I'll let Magnus decide for this matter.

Regarding code reviews

Indeed, there are a lot of quirky decisions and repeated code, but that's normal for now.
For now, I'm more interested in making this work and have a working patch for the entire email sending workflow.
Lots of things are probably useless and redundant, so apologies if I'm giving you stomachache :P

Stay tuned for another patch.

Think about the scenario where you're writing an address, and you need to copy it from another window, or maybe you click somewhere else to view another email and confirm the address, and the pill reverts back losing your temporary editing.

Ah, good point. Suggestion withdrawn. That is too bad about the width of the autocomplete panel.

Exciting stuff happening here, thanks everyone, and special thanks to Alessandro for taking on the beast!

1.) Could we fine-tune the click pattern for "edit pill" & friends a bit?

Single-click on pill: Select pill (select more pills with Ctrl+click/shift-click)
Single-click on selected pill: Edit pill ***
Double-click on pill: open associated contact (create new contact if not yet associated)

Rationale: Exploit users' habitual click-patterns from other, similar tasks, e.g. selecting and renaming files in Explorer (ux-consistency).

*** "Edit pill" probably refers to a direct, one-time edit, right? As opposed to changing a possibly associated contact in the address book.

2.) I'm not so sure yet about the best behaviour for outside clicks while editing pill (leaning towards exiting edit mode), but definitely we can't have a situation where multiple pills are in edit mode, as was pointed out above.

3.) Thunderbird users have been with neat, vertically aligned addresses forever; I'd think that for many users this may have become more than habit formation, they might actually appreciate this as a distinctive feature. The UX is poor not mainly because of the vertical alignment, but because of technical design and behaviour shortcomings, e.g. that we can't batch-change multiple addresses from To to BCC (in fact, we can't even select and copy multiple addresses). Also note that some of the behavioural shortcomings have been addressed in the current release version, e.g. recipients can now be navigated with cursor up/down, click to select single recipient has been implemented (pill-style), DEL and Backspace now allow controlled and predictable sequential deletion of multiple recipients with 2 keystrokes each.

I recommend:

• allowing some way of vertically aligning/sorting/etc. recipients in the new pill scheme of things (not doing so may significantly irritate existing users). This might be as "simple" as having a "legacy view" which only allows one pill per line. As others have suggested, we should try to separate views from content/roles, and explore creative variants like multi-column views of pills.
• to ease the transition for existing users, allow a two-click (or single-click) way of changing the recipient type of each pill (contextual action, hover menu etc.).
• addressing the existing UX shortcomings in the pill scheme (provide multi-select and allow multi-selection-actions like mass-changing recipient type, mass-deletion, mass-copy etc.

I'm aware that some of these might require an incremental approach, but we should ensure now that the new design allows for such.

All right, here's another big improvement.

Keyboard navigation

• Now you can navigate between pills with the arrow keys and tab.
• If you hold CTRL, you can select multiple pills both with the click and the arrow navigation.
• CTRL+A will select all the pills if one is already selected (I need to add this to the input field as well).
• You can delete multiple selected pills.

Context Menu

• Pills have context menu which allow to edit, delete, and copy the email address.

Cc, Bcc, etc.

• The other fields are there and can be revealed by clicking on the label.
• You can hide the field back, and get prompted with a confirm dialog if the field has addresses in it.
• The header area grows to accommodate all the pills and fields, but as soon as you resize it, the area turns scrollable.

What's missing

• Making this thing actually work and send emails.
• Populate the fields when forwarding an email.
• Add Drag&Drop for the pills.

As usual, the overall code is very dirty, with lots of repetitions and some nasty solutions. I'm doing it this way for the sake of having a fully working prototype which we can later iterate to optimize.

The next patch I'll upload should come with everything currently missing, and we can start the review process.

Thank you again everyone for the insightful feedback and your patience on waiting on this monolith.

Hi, I'm the developer of MRC Compose.

Alessandro, from what I saw with screenshots, you're doing a great job ! Thank you to take care of such an important point in Thunderbird.
Are you ok if I try to integrate some parts of your prototype (ideas/code) in MRC Compose ? It's something I wanted to do from the beginning, but it requires so much low-level handling that I always postponed it.
Would you like to be notified of any progress I may make ?

Cheers,
Michel

PS: MRC Compose is now compatible with TB68 and can search in Cardbook !

(In reply to Paul Morris [:pmorris] from comment #120)

If I may suggest as an end-user...

• Do we want to alert the user that they are deleting addresses by closing Cc, Bcc, etc. or allow them to undo it after the fact?

Hiding Cc,Bcc,etc... shall not remove content in the first place... it should just hide it... addresses shall only be deleted if delete action is triggeref by end-user.

• Backspace or delete to remove all pills. If one is in editing mode, you get stuck on it. Backspace (or delete) stops having any effect.

For me a pill in edit mode is just a pill converted back to simple editable text (no pill anymore), as it was before it became a pill. It would be much simpler behaviour in concept. We should try to keep To,Cc,Bcc as close as possible to editable text fields, the pill system being just a visual and management aid.

Hitting backspace would simply erase text... if text become empty and you keep backspacing, I would expect previous pill (if exist) to convert back to text, and characters to start being deleted again...

Similar behaviour with the delete key.

• Start editing a pill, delete all text in it, hit enter, nothing happens. I'd expect the pill to be deleted.

If pill in edit mode become just text, if empty text I would expect the pill to no longer exists (effectively deleted). You would just end up with curser between two pills. Therefore hitting enter having no effect an empty text being not a valid email address to convert back into pill.

In a similar way, if I place cursor between two pills and hit Backspace (or Delete), it would convert previous (or next) Pill into editable text that you can further delete (per character) or amend... in a very similar way to editing a simple text...

• Click a pill to select it. Hit tab to move to the next pill. The first pill stays selected in addition to the next pill.

A bug it seems... hitting tab shall shall move selection to next tab. Previous selected pill shall remain selected only if shift+tab wss pressed together.

• If a pill that's not the first or last pill is in editing mode and you use the arrow keys to try and navigate to it and past it, it doesn't work like with tab and shift+tab. When you get to that pill you can't arrow key away from it, only tab into it to edit it some more. Arrow keys should work like tab and shift+tab for pills in editing mode.

If pill is convert back to text (edit mode) I would expect arrows to only allow navigation within the editable text.

Though one could imagine that if you reach start (or end of text) and keep pressing left arrrow (or right arrow):

• if edited text email address is valid, it would convert the text into a pill, and set the previous (or next pill) into edit mode
  OR
• if not valid, do nothing (just raise alert that address is invalid and must be valid)

• When a pill is in editing mode, maybe show a "checkmark" button (or
  similiar, in the place where the "X" button is), that would do the same as
  hitting "enter" on keyboard? Then if I switch away from an editing pill, I
  can get it out of editing mode directly by using the mouse.

For me editing mode should just be text mode... no longer a pill... therefore there should be no need for such checkmark... just nee to hit Enter to convert text back into pill (or via click outside editided text).

• If the last pill is in editing mode, you can't move the cursor to the text input to add another address without taking the pill out of editing mode first.

Again editing mode shall just be text mode.

• It seems a little odd to have more than one pill in editing mode, but maybe it's fine and just a matter of getting used to it.

As edit mode is just text mode it allow to enter (or edit) multiple addresses at once... especially handy when copy/pasting multiple addresses from wherr else...

Though I would expect to only be able to edit one pills at a time after convertion not multiple unless they are next to next...

Another patch, another iteration.

What's new

• Now you can CTRL+C and CTRL+X on the pills to copy or cut them, it works for single or multiple selected pills at once.
• The various selection interactions should have been fixed.
• Add addresses from Address Book has been fixed.
• Hitting Enter on and an empty pill while editing will delete that pill.

Pills interactions

• If you're editing a pill and you keep hitting backspace or delete the pill WILL NOT be deleted. This is to prevent accidental and unwanted deletion while clearing out wrong addresses.
• While in editing mode, the arrow keys won't allow switching from a pill to another. This is to prevent accidentally leaving the pill which it can be extremely annoying. Also, hijacking the arrow keys inside an input field is not great.

Alerting the user when removing a row with pills in it
Yes, we should absolutely prompt the user with a confirm, and we should clear that row if the user decides to remove it.
Imagine the scenario where the user is forwarding an email with 100+ addresses inside the CC container. The user deletes that container because it doesn't need it and starts editing the content. Then, he realizes he needs to CC that email to another contact and reopens the CC container, finding once again the 100+ addresses he though he deleted.
The very own X button, which implies the deletion of a row, can't trick the user by not actually deleting the content within.
It's linear, makes more sense, and it avoids us developers doing a check on submit like "the CC field has 100+ addresses, but it's hidden, so don't use them".

Since this patch is getting pretty big, I won't implement the Drag&Drop feature in here, but I will do that as a follow up bug after this first iteration lands on daily.

Looks good. Here are a few new things I noticed, but nothing that should block this from landing, just potential follow-up polishing stuff.

• Maybe add "cut" to pill context menu.
• After cutting and pasting a grey background, in-address-book pill the background was orange on the second instance, so not recognized as in the address book.
• Should you be able to tab to the "X" button for removing Cc/Bcc/Reply-to row? Currently you can't tab to them.

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

The .address-container doesn't work well with dark theme, can be fixed later.

Ah yes, I will definitely need your expertise to be sure everything looks top notch in dark mode.

Mailing lists pills are coloured red like invalid addresses.

This should have been fixed in the upcoming patch.

(In reply to Paul Morris [:pmorris] from comment #125)

Maybe add "cut" to pill context menu.

Done.

After cutting and pasting a grey background, in-address-book pill the background was orange on the second instance, so not recognized as in the address book.

Fixed.

Should you be able to tab to the "X" button for removing Cc/Bcc/Reply-to row? Currently you can't tab to them.

Good call, done.

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

I don't particularly like how the Cc Bcc Reply-to Newsgroup Followup-to field names are lined up under the To line.

Indeed, that's not an optimal placement. I'm experimenting with other locations, one of which is inline the To field, right aligned.
Also, I'm thinking about "hiding" the less common labels behind a dropdown menu. I'm not sure yet, still trying to find the best solution.

Also we'd not want to have the Newsgroup and Followup-To ones there showing for all mails.

That shouldn't be the case as I've updated the code in the hideIrrelevantAddressingOptions() to not show those fields based on the account type.

For the To row, what's not working atm is at least entering addresses that aren't in your ab already.

That works for me, can you elaborate on that? If you write a new address and you hit Enter, what happens?

And commas between addresses should work.

That works for me as well. If I write multiple addresses separated by a comma and then hit Enter, all those addresses are converted into pills.

The Subject "box" seem to have lost its top border.

It never had a top border. It has always been the bottom border of the field above.
Moving the Cc, Bcc, etc, labels to the right should fix that visual "issue".

I'm still struggling a bit with the email submission and the automatic fill-up of the fields on replied or forwarded emails.
Those methods are tightly coupled with so much stuff that it's giving me a hard time.

Sorry for the delay. A new patch ready for review will be uploaded ASAP.

Try this: add an address with autocomplete, then try to add an address that's not in the addressbook.
You shouldn't have to press enter either. Once you add a comma it's the next address.

Ah, I see, that's a UX issue.

In order to solve this I've implemented the creation of the pill when the comma character is pressed, or onblur of the input field with a valid email address.
You're right, users shouldn't be force to hit Enter or Tab to create a pill.

Thanks for the detailed explanation.

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

Ah, I see, that's a UX issue.

In order to solve this I've implemented the creation of the pill when the comma character is pressed...

Would semi-colon ';' be usable as email address separator? Basically having same effect as comma ','? This may bring some flexibility especially for copy/paste, if not directly by end-user possible habits...

When To, Cc, Bcc are empty would there be any hint text in the field to indicate to 'Enter email addresses comma or semi-colon separated' as a tip? May be handy for new or accustomed users ;-)

All right, I think it's time to start the first of (I suspect) many reviews.

The whole workflow works now.
Sending emails work.
The various forward, reply, etc, work.
Writing to an entire list work.

Old methods
I started removing the unused methods of duplicating rows and checking for dummy_rows, but I think I'll stop for now as some of those methods are tightly coupled with the Address Book methods.
I will take care of those in a follow up clean-up patch.

UI and UX
Currently not at a great state, but if it's OK for you Magnus, I'd like to focus on landing a working and usable patch, with all the tests green, to then follow up with a UI-centric patch on a different bug.
Having the working prototype will help me to define better what we need and how it should be improved.

Tests
All the tests are failing, obviously, but I will hold off on those until this patch gets an r+.

What's missing
Dropping email addresses on a field is broken, but it should come in the next patch.

Thanks everyone for reviewing this beast.

Would semi-colon ';' be usable as email address separator?

Done :D

Re semi-colon: I think you shouldn't. Pasting will do the right thing nowadays. Eventually we want to support group syntax and I wouldn't want to have users wrongly trained to use it.

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

Pasting will do the right thing nowadays.

You mean it would convert semi-colon into commas and convert addresses into pills on the fly?

Eventually we want to support group syntax

How using semi-colon as separator prevent group syntax?

Is there an RFC or other reference that indicate/recommand semi-colon as email separator for group/distribution list?

Is your idea to be able to create an auto-completion group by just typing email addresses separated by semi-colon?

and I wouldn't want to have users wrongly trained to use it.

You may be right on this, maybe then accept it as a valid separator but don't encourage it...?

This would bring flexibility - some email client use semi-colon as separator or accept it as alternative to coma...

Unless of course you have other plan/idea...

Just try copy-pasting something with semi-colon and you'll see we make that right (already on release).

Group syntax is RFC 5322, see "Group Addresses". Like "Family: Foo <foo@example.com>, Bar <bar@example.com>"; "Friends: Joe <joe@example.com";

Could someone kindly offer a try build? TIA.

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

Could someone kindly offer a try build? TIA.

I'll do that later once the majority of the tests are fixed, and a couple of missing features are added to the patch.
Probably before the end of this week.

Here's another patch with more improvements:

• Address Book lists are now recognized and properly styled.
• Drag and Drop of addresses from the Address Book sidebar to the field works, as well as dropping them on top of the labels.
• All the Address Book methods have been moved to the dedicated JS file. The addressingWidgetOverlay.js now handles only the compose dialog methods.

Here's a try run with all the builds:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=2bb73e8838882784652dd6e5d91640d5474bb9c2

Be aware that:

• All the tests will fail.
• The UI is not final and many improvements will come in the next days.

Please, test it and report issues!
I'm sure this patch will introduce many many many regressions, so, ignoring the fact that this bug is gonna probably reach 200+ comments, I'd like to ask anyone interested to grab a build, test it, and report any issue or bug you stumble upon.

I'm testing the patch, and it works really well! I like the UI design, too.

A few minor glitches that I noticed and that should be easy to fix:

• It's too happy to make entries without email address. E.g. "where.com" results in "where.com <>" in a red pill (where.com <> [x]). I don't think such entries with syntactically invalid email address should be created at all. As pill, they look valid, even if red. And as pill, they are hard or impossible to fix. I think they should just stay text until they are fixed.
• It's a little to quick to end the entry and create a pill. E.g. on my keyboard, the comma , (which creates a new pill) is right next to . (which I need for an email address), and I've repeatedly accidentally create a new pill when I didn't want to. Once it's a pill, it's hard to fix. Not sure how I'd solve that.
• Backspacing into a pill should not delete the pill, but re-enter edit mode and delete only the last characters. Probably similar for other key strokes like arrow keys and others.

All these are minor "editor rules" issues. Technically, this works really well, from what I'm seen in my quick test. Good job!

Style (sorry for the bike-shedding):

• I don't like the colors, esp. the yellow. I'd stick to a more conventional grey. Color doesn't fit here.
• The contrast between foreground color and background is too low.
• If you use red for error (I'd rather not create a pill at all in this case, see above), make the red much more flashy.

(In reply to Ben Bucksch (:BenB) from comment #139)

• Backspacing into a pill should not delete the pill, but re-enter edit mode and delete only the last characters.

Please don't. Backspacing onto a pill should delete the pill, and consecutive backspaces should delete pills backwards one by one. Backspacing to delete character-wise only makes sense for a single pill in edit mode. It's highly unlikely that user needs to edit more than one or two odd pills in a delete-per-character fashion, whereas it's much more likely that recipients need to be removed. We have just introduced the distinction in bug 1527547 to improve the UX-efficiency of removing recipients, and it works well: For editing a single recipient, backspace deletes characterwise until that recipient (display name and email address text) is completely deleted. Pressing backspace again on an empty recipient row will remove the row and start removing recipients one by one. I haven't tried pills yet, so I'll comment again after that, but I believe wrt keyboard deletion pills should behave similar to the current release version behaviour, where my patch of bug 1527547 has created a precursory pill-style experience.

(In reply to Ben Bucksch (:BenB) from comment #139)

It's too happy to make entries without email address. E.g. "where.com" results in "where.com <>" in a red pill (where.com <> [x]).

Good call. Text won't be converted into pills if the address is not valid.

It's a little to quick to end the entry and create a pill. E.g. on my keyboard, the comma , (which creates a new pill) is right next to . (which I need for an email address), and I've repeatedly accidentally create a new pill when I didn't want to. Once it's a pill, it's hard to fix. Not sure how I'd solve that.

If this happens, you can easily edit the pill by using the left arrow key to select the pill, then press Enter to enable edit mode, and now you can edit the pill address.
Anyway, this problem should be solved because even if you hit , accidentally, the pill won't be created because the string doesn't contain a valid email address.

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

• The fields are no more vertically aligned in columns because the text fields begins directly after the To: label.

The UI is not polished at all and I'll need to iterate on it a bit more to find a better overall solution.

When I DnD a valid address from sidebar the address is shown red first until I press the ENTER button or click in a other text field. A valid address should never be red and when dropping a address from the sidebar it should change immediately convert to a pill.

We found out that the patch was outdated, so these issues have been fixed in the most recent patch.

I have a little problem with character encoding. When the pill gets created from an address with special characters (eg. ö) those characters turn into a question mark.
That's pretty odd as I'm simply storing those values into a label inside a custom element.
Does anyone know if custom elements need an encoding attribute, or the UTF-8 charset needs to be specified somewhere?

I'm attaching a screenshot of the issue right after this message.

Thanks everyone for the feedback and the help.

Here's the outcome of an address saved into a label value.

Please also check with these 4 characters: ŐőŰű

https://www.compart.com/en/unicode/U+0150
https://www.compart.com/en/unicode/U+0151
https://www.compart.com/en/unicode/U+0170
https://www.compart.com/en/unicode/U+0171

For an test email address, please try:
ÁáÉéÍíÓóÖöŐőÚúŰű, Testing <ÁáÉéÍíÓóÖöŐőÚúŰű@example.com>

What do you think?

Thank you

All right, here's an updated patch with everything that was highlighted by Magnus.
I also fixed the wrong charset when dealing with special characters.

The originalInput is really confusing. Maybe it just needs a better name and documentation. It's just the base name?

Yeah, I'm not happy with the name either.
That is the ID of the autocomplete html:input where the pill was generated from. I need that to ensure keyboard navigation and focusing on it if all the pills are delete.
Which name would make more sense? I added a comment but I'm not sure it's clear.

We should avoid putting random attributes on standard elements like this. Is there a better way to handle this?

True, sorry about that. I ended up using the control attribute to reference the html:input. I didn't need a custom attribute at all.

Onto fixing all the failing tests.

Had to interrupt my holiday to check this out. Looking good :-)

Oops, spoke to early. Try this: Create a Cc field. Summon the addressing side bar or open an address book. Try dragging an address to the Cc field :-( - I don't want to mention that this malfunction could be quite fatal when a Bcc address is added to the To field.

(In reply to Jorg K (GMT+1) (PTO to 1st Dec 2019, not reading bugmail) from comment #149)

Oops, spoke to early. Try this: Create a Cc field. Summon the addressing side bar or open an address book. Try dragging an address to the Cc field :-( - I don't want to mention that this malfunction could be quite fatal when a Bcc address is added to the To field.

Ah, I see why this is happening.
Most likely you didn't drop the address exactly on the label, which it doesn't grow 100% of the column's width, and by default if a drop area is not recognized it falls back to the To field.

So, it's a matter of CSS and ensuring the the entire address row is accepted as a correct drop area, and not just the label or the input field.
Thanks for testing it and reporting this.

I started tackling the majority of the failing tests and I'm moving forward towards a green try run.

While updating tests, I was able to nail down some quirks and unexpected wrong behaviours, hopefully with the remaining tests to fix, I will lower the number of potential regressions to a manageable amount.

Here's a fresh try-build for anyone interested in testing it: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=16ba5865ee16850d0f618d7e49c900a83ac6b126

I was able to nail down some quirks and unexpected wrong behaviours

Including fixing comment #149? I was dragging onto the field, not the label, BTW.

This is ready for a full review as all the tests on Linux have been fixed.
I've also been using daily with this patch applied all day to send emails and I didn't stumble upon any issue...so far.

Here's the try run: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=37715c9cc02dcb65deeb5c40b1f40a728a9c6a94

There are a couple of tests failing on macos, which I will fix tomorrow since I have to update the UI and dark theme variation for that platform.

Here's a patch to apply on top of the original one to implement a slicker and more refined UI.
This is good to test only on Linux for now as I will be tackling macos issues tomorrow.

Repeating: Have you addressed comment #149? (see comment #152).

(In reply to Jorg K (GMT+1) (PTO to 1st Dec 2019, not reading bugmail) from comment #155)

Repeating: Have you addressed comment #149? (see comment #152).

Yes. Sorry, I meant to answer your question in my previous comment but I forgot.
I tested it on Linux and macos and it works. Now, it shouldn't matter where you drop the address on the entire row, the field should always be the expected one.

Issues I found, not fatal and some could be done in follow-up patches/bugs.

• I think, the drop-shadow of the boxes is too dark. First when I saw it, I thought there must be a popup below that doesn't open correctly ( I was in the "From" menulist). With dark theme the drop-shadow is very hardly visible.
• It seems depending on the recipient pill's length it calculates if a second pill will match on the same line. If not it expands already the text box to a second line (see screenshot Bcc field) which looks a bit weird when there is still enough space to enter an address. I think, it should only expand when the cursor touches the box on the end.
• It would be great when we have a feedback, like the mouse hover feedback, when I try to drop an address on the "Add Cc", "Add Bcc" etc. buttons.
• The text boxes grow by 1px when the first address converts to a pill (no pill in box, 29px, with pill 30.33px).
• Dragging the pills to re-order/move to an other box isn't possible. For me okay for a follow-up bug.
• Also for a follow-up bug: maybe add a "Edit Contact" menu item like we have on the message header address.

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

Thanks for the feedback, I'll fix what you reported.
Here some thoughts on what you suggested.

It seems depending on the recipient pill's length it calculates if a second pill will match on the same line. If not it expands already the text box to a second line (see screenshot Bcc field) which looks a bit weird when there is still enough space to enter an address. I think, it should only expand when the cursor touches the box on the end.

That's an issue Paul pointed out before, and I agree that it looks awful. The problem is that I need a min-width for the input field in order to have a decently sized autocomplete popup. If I let the main input field shrink to fit inline with previous pills, the autocomplete popup will be too small since it inherits the width from the input field.
I'll see if I can force the popup to use the entire row container (which is styled to look like an input field but is not) as a width reference.

It would be great when we have a feedback, like the mouse hover feedback, when I try to drop an address on the "Add Cc", "Add Bcc" etc. buttons.
Dragging the pills to re-order/move to an other box isn't possible. For me okay for a follow-up bug.

Yeah. Both these edits will come in a follow up bug where I'll focus only on implementing a proper Drag& Drop experience.

(In reply to Paul Morris [:pmorris] from comment #159)

I cut and pasted a large number of comma separated addresses, say 50-100, into the To field and then hit enter to turn them into pills.
The field expanded vertically for all the pills to fit, and that pushed the rest of the UI off the bottom of the window, and there was no way to scroll to bring it back into view.

Uh oh, that's not supposed to happen, and it's definitely a bug.
I have a check in place to see if the header area grows taller than 2/3 of the window height whenever a pill is created, and if it does it should stop growing and add overflow scroll.
I'll fix that.

Here's another patch with a fix for the issue reported by Paul.
The try run is looking pretty green, except for a couple of failures I'm not sure how to deal with: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=d13eaf801f2df3b4d15e51bd0e1b3aaffe0a7055

X3 failure: security/manager/ssl/tests/unit/test_intermediate_preloads.js
How can I run this locally and debug it? It's part of m-c.

Z4 failure: That's a whole crash of the app happening on macos only. But when I test it locally I can't seem to recreate the issue and all the tests pass. Any advice?

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

X3 failure: security/manager/ssl/tests/unit/test_intermediate_preloads.js
How can I run this locally and debug it? It's part of m-c.>

./mach test security/manager/ssl/tests/unit/test_intermediate_preloads.js

Probably not related though

Z4 failure: That's a whole crash of the app happening on macos only. But when I test it locally I can't seem to recreate the issue and all the tests pass. Any advice?

Probably not from your patch.

X3 failure: security/manager/ssl/tests/unit/test_intermediate_preloads.js
Ignore. The person keeping the tree green should have filed a bug and fixed it. Started this morning, Thu, Nov 28, 06:06:07.

I see both X3 and Z4 happened in other try runs without my patch applied.
Thanks both for the info.

And this is the updated UI patch with the following changes:

• Light and Dark theme styled for Linux and macos (Windows currently missing).
• Added shortcuts for macos.
• Prevent input field from showing an empty blank row.
• The autocomplete popup is attached to the row container and not the small input field.

I'm currently working on the other UI solution, which will come on a patch to apply on top of this.

Since the other UI variation only changes the location of the other recipient labels, I will not upload it until this one gets reviewed and approved in terms of colours and sizing.

Added the Windows styles. Also removed a lot of no more used code. I also tried to align vertically the labels to the text inside the fields.

I had to move some code from shared to the platform files to not to have to revert styles we don't need?

On Mac I added the box-shadow: var(--focus-ring-box-shadow); to the boxes to make it look more like the default focus on Mac.

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

Autocomplete by adding comma + entering the next person doesn't work unless it's the first comma. I think we should also be consistent with commas and maybe add them between each recipient.

Can you elaborate on this? Sorry, but I don't think I understood what problem you encountered.
The comma is currently handled in 2 scenarios:

• While typing, if you press comma, the test before gets converted into a pill.
• When pasting multiple addresses separated by a comma, those get converted into pills on Enter or blur.

Leaving a pill in editing mode when you click outside works oddly. I know
there were some use cases listed in comments above, but it's unexpected. And
if you, say, move on to body - has it taken affect or not...?

All right, too many people gave the same feedback on this, so I guess we can see how the users react on a pill exiting edit mode on blur.

::: mail/base/content/mailWidgets.js

  ".emaillabel": "crop,value=label",

since this is a a new element, instead of mapping value to label, we could just use label. I think that's clearer too.

Could you point me to an example? I don't think I got what you mean, sorry.

I don't think this belongs here. An element is self-contained and shouldn't be allowed to look into the parent.
...
same here

I moved the get pills(), get allPills(), and get allSelectedPills() methods to the AddressingWidgetOverlay.js file

@paran {HTMLElement} input - The autocomplete input field.

But is there something off here? Should it be selectRecipientPill? (without
s). If not, how can you focus()?

When the focus is on the html:input and the user hits CTRL+A I'm moving the focus on the latest pill present in the container.
All the available pills in the same row get the selected attribute, but the focus should move on one pill in order to handle the mass cut, copy, and delete actions.

function GetMsgToRecipientElement() {

maybe we can just get rid of this... there's no need for caching and all it
does is look up the element by id which is super fast

The gMsgToRecipientElement variable is used a couple of times in the SwitchElementFocus() method to handle the focus via F6.
How would you suggest updating that method?

All the other points have been feedback.
I'm gonna merge the UI patch into this in order to have everything together into a single patch and avoid dealing with merging issues while updating the base patch.

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

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

Autocomplete by adding comma + entering the next person doesn't work unless it's the first comma. I think we should also be consistent with commas and maybe add them between each recipient.

Can you elaborate on this? Sorry, but I don't think I understood what problem you encountered.
The comma is currently handled in 2 scenarios:

• While typing, if you press comma, the test before gets converted into a pill.

It doesn't seem to work if you autocompleted, get the pill, and then add a comma (doesn't trigger autocomplete when you write then). Also for cases you come back to fill in more addresses.

All right, too many people gave the same feedback on this, so I guess we can see how the users react on a pill exiting edit mode on blur.

I think that would be preferable yes.

::: mail/base/content/mailWidgets.js

  ".emaillabel": "crop,value=label",

since this is a a new element, instead of mapping value to label, we could just use label. I think that's clearer too.

Could you point me to an example? I don't think I got what you mean, sorry.

For the above mapping it means you'd set pill.value="foo" to get the label to be foo. Seems more readable to just have it be pill.label="foo" to set the label. So the rule would be ".emaillabel": "crop,label",.

I don't think this belongs here. An element is self-contained and shouldn't be allowed to look into the parent.
...
same here

I moved the get pills(), get allPills(), and get allSelectedPills() methods to the AddressingWidgetOverlay.js file

@paran {HTMLElement} input - The autocomplete input field.

But is there something off here? Should it be selectRecipientPill? (without
s). If not, how can you focus()?

When the focus is on the html:input and the user hits CTRL+A I'm moving the focus on the latest pill present in the container.
All the available pills in the same row get the selected attribute, but the focus should move on one pill in order to handle the mass cut, copy, and delete actions.

function GetMsgToRecipientElement() {

maybe we can just get rid of this... there's no need for caching and all it
does is look up the element by id which is super fast

The gMsgToRecipientElement variable is used a couple of times in the SwitchElementFocus() method to handle the focus via F6.
How would you suggest updating that method?

Use document.getElementById to get it when needed.

On a more general note, the "Add Newsgroup" and "Add Followup-To" headers are now quite in your face, so to speak. They used to be much more hidden. I'm not sure what you have planned for them? The other UI alternatives you sent would have been nicer re that. As is, I think this will be confusing to many, who have no idea even what a newsgroup is.

For the pill styling, maybe they should be less rounded in the corners?

For newsgroups, the confirmation of removing the field does not show.

I implemented the full UI for solution 1 in this new patch, and fixed almost everything that was reported.
Here's a couple of follow ups:

It doesn't seem to work if you autocompleted, get the pill, and then add a comma (doesn't trigger autocomplete when you write then). Also for cases you come back to fill in more addresses.

Why would you type a comma after a pill is created? After an address is converted into a pill, it should be natural to just type a new address since the previously typed value was converted, and there's no need to write a comma between pills.
Sorry if I misunderstood what you wrote.

For the above mapping it means you'd set pill.value="foo" to get the label to be foo. Seems more readable to just have it be pill.label="foo" to set the label. So the rule would be ".emaillabel": "crop,label".

That's not really what I'm doing.
The pills structure is the following:

<pill>
  <label class="emaillabel"/>
  <html:input>
</pill>

So when I set pill.label="foo", which is what I'm doing when creating a new pill, the child <label> gets that attribute and adds it to its value:

<pill label="foo">
  <label class="emaillabel" value="foo"/>
  <html:input>
</pill>

Is this a wrong approach?

I removed the gMsgToRecipientElement variable. Do you want me to do the same for gMsgIdentityElement and gMsgSubjectElement since they're doing the same thing?

On a more general note, the "Add Newsgroup" and "Add Followup-To" headers are now quite in your face, so to speak. They used to be much more hidden. I'm not sure what you have planned for them? The other UI alternatives you sent would have been nicer re that. As is, I think this will be confusing to many, who have no idea even what a newsgroup is.

This patch comes with the proposed solution 1 applied.
I'm now working on a dedicated patch for solution 2, with the labels inline the To field so we can test both by simply apply the secondary patch on top of this.

I know you're not a fan of this solution, but I wanted to avoid working on solution 2 before the overall code and base structure was close to a somewhat final state. :)

For the pill styling, maybe they should be less rounded in the corners?

I recommend to leave it like that. The rounded border style is a pretty common solution in other email clients, and the fact that it's not used anywhere else in the software it makes the pill a more recognizable element and unique to an email address.

For newsgroups, the confirmation of removing the field does not show.

Fixed.

And here's the patch with solution 2 for the UI.
This patch puts the most common extra recipients inline with the To container, and collects extra recipients inside a popup panel.

Richard, let me know if I messed something up, especially on Windows.
Cheers

I had to rebase the patch and fix various merging issues with the latest updates that landed on trunk.

And also this one is rebased.
Here's also a try run, let's see how this one goes: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=0c8944c58d1c7f43fbd6299ae93dec5f66ff6805

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

Why would you type a comma after a pill is created?

I'd like the commas to be visible. Why you'd write it - well if you know commas separate emails, it's a natural thing to do so it shouldn't send you off to an error mode.

Is this a wrong approach?

Ah, I misread. Please ignore.

I removed the gMsgToRecipientElement variable. Do you want me to do the same for gMsgIdentityElement and gMsgSubjectElement since they're doing the same thing?

Sure, but feel free to do it in a followup.