Open Bug 1696994 Opened 4 years ago Updated 4 years ago

Cannot enter certain display names or emails containing @ and comma combinations

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 88
defect

Tracking

(Not tracked)

People

(Reporter: henry-x, Unassigned)

Details

Attachments

(1 file)

Certain addresses or display names cannot be entered even though they are technically valid email addresses or display names.

To see what I mean, compose a new message and try and add the addresses:

  1. ex@,mple <example@org>
  2. example@(comment, with comma)org
  3. ex@mple <(comment, with comma)example@org>

These are weird but are meant to be valid addresses (I think something like the first case is the most likely to crop up in normal use), but in each case the address ends up being split in half after the comma character instead of remaining a single valid address.

There doesn't seem to be a work around since I get the same problem with each of the following methods:

  • typing each character one by one (entry is split in two)
  • pasting in full into the address box and pressing enter or blurring (split in two)
  • editing an existing pill to change the content (remains a single pill but it is truncated)
  • auto-completing using an the address book entry (split in two)
  • using the Write context menu in the address book window (split in two)

I think the problem is that any entry that contains an @ that is not at the very start or end is already considered a valid address (through isValidAddress https://searchfox.org/comm-central/rev/d53f614c98630c0a73a73f376955f79fa3773b36/mail/components/compose/content/MsgComposeCommands.js#4868). So when the @ character is followed by a comma character it is assumed that a valid address already exists and has been terminated by the comma as a separator.

It would be good to have a way to support entering the above addresses and similar. I can understand when typing or pasting into the address field, we could safely assume in most cases that a comma after an @ ends a recipient. But it might be good to be able to override this behaviour in these cases:

  • editing an existing pill to change the content
  • auto-completing through the address book
  • using the Write context menu in the address book window

In all these cases, I don't think a user would expect the current behaviour of splitting or truncating.

Severity: -- → S2
Severity: S2 → S3
ex@,mple <example@org>
example@(comment, with comma)org
ex@mple <(comment, with comma)example@org>

Are these potential valid addresses?
I'm worried we might focus on extremely rare edge cases that we'll never encounter.

auto-completing through the address book

If I'm not wrong, this should already work if you have an address in the AB that has a comma, for example in the display name, it shouldn't autocomplete while typing it. We implemented this with Thomas.
E.g.: If you have Doe, John <doe.john@example.com> saved in your AB, and you type Doe, in the addressing field, it shouldn't autocomplete.

I agree that the isValidAddress method is extremely simplistic and should be improved.
There's also another thing to consider, which is the MailServices.headerParser.* methods that if I'm not wrong sometimes they wrongly parse or split strings of addresses if the comma is in a strange position.
I think Thomas stumbled upon this issue a couple of times.

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

ex@,mple <example@org>
example@(comment, with comma)org
ex@mple <(comment, with comma)example@org>

Are these potential valid addresses?
I'm worried we might focus on extremely rare edge cases that we'll never encounter.

These are valid email addresses (comments are part of the specification, but I don't think they are used often). But its true that in each of these examples you could still send the email. You would just have to remove the comment and change the display name. So this isn't blocking emails, just potentially getting in the way.

Although, I just checked, and when I sent an email to myself with the display name ex@,mple (using the website, rather than thunderbird) and then clicked "Reply" in thunderbird, the reply address was broken in two! So I suppose this could be used to annoy thunderbird users ;)

I still think it would be nice to be able to handle these cases. I also think it makes sense that in the internal logic, we should handle whatever the user enters in an existing pill or their address book simply as they requested, rather than trying to be smart and split them. Being smart is useful for live entry to make things speedy, but if the user then goes back and edits the pill or uses the address book they probably want it to be what they set. But I suppose this would be a question of if this will ever happen in normal use.

auto-completing through the address book

If I'm not wrong, this should already work if you have an address in the AB that has a comma, for example in the display name, it shouldn't autocomplete while typing it. We implemented this with Thomas.

The examples show that this doesn't work when an @ comes before the comma. I'll attach an image to show what I mean.

I agree that the isValidAddress method is extremely simplistic and should be improved.
There's also another thing to consider, which is the MailServices.headerParser.* methods that if I'm not wrong sometimes they wrongly parse or split strings of addresses if the comma is in a strange position.
I think Thomas stumbled upon this issue a couple of times.

I think isValidAddress is relevant to this problem, but it wouldn't fix it. For example, a user could always set a display name in their address book to be eg <eg@org>,, which would make their full address entry eg <eg@org>, <ex@org>. Now, the first part before the comma in itself is a valid address, but that doesn't mean the user would want it to to always spawn two separate pills. On the other hand, this user is asking for trouble! Note that in Fastmail, they handle this by using quotes "eg <eg@org>," <ex@org>, but we have pills so we shouldn't need this (the final <> contain the email, everything else is the display name).

I think this is more about the lack of a distinction between typing or pasting into the address book entry (where we can be smart), and creating the pills through the address book, or editing an existing pill, or on "Reply". But it may not be worth the extra upkeep to create this distinction.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: