1039443 - Recipient area should quote display names with commas in them (e.g. "LastName, FirstName")

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, defect)

Description

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

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

In tb24 addresses as suggested in autocomplete had double quotes around them when needed, like an address "Lastname, Firstname" <[e-mail]>

After jcranmers js mime rework these quotes are now no longer present, except during send, where it otherwise would not work.

In general we do not want or need quotes, but for commas in names I do dislike not quoting the display name in the composition area. It may be a tad techy, I admit, but addresses should be separated with commas and it's very confusing if you have a mix and enter several addresses on the same line. This case is actually broken as is (and fixed by this patch)
E.g. copy paste into To: lastname, firstname <[e-mail]>, foo <[e-mail]

The addressing area should help you create correct syntax from start, and without quotes I don't know how you could even make groups work with a comma-displayname.

"Green" try for (almost) the patch attached.
https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=79a70023dd3d

Also includes a mozmill test for autocomplete comma display name.

Comment 1

[Joshua Cranmer [:jcranmer]]

Comment on attachment 8456802 [details] [diff] [review]
proposed fix

Review of attachment 8456802 [details] [diff] [review]:
-----------------------------------------------------------------

I can't in good conscious recommend an r+ for this patch.

First off, I disagree heavily about the notion that we should even display the quotes here. But let's leave that aside for the moment.

I am extremely skeptical that the quotation mechanism you provide here is actually doing what you want it to do. Yes, you have a test that it displays in the compose window correctly, but that's not the real issue. I suspect that if you let it get out to the MIME message, you'd have:
To: "\"Bond, James\"" <blah@blah>
which is not what you want.

But that's not the bigger issue. The problem is that quoting really mangles strings--you effectively need to make the reparser assume that it's a possibly-quoted string in the first place, which leads to issues for how to properly represent things like «John "The Bomb" Smith».

My distaste from quoting in part arises from cases where you need to start throwing \ in displayed UI, and I think when you look at quoting in just a "simple" case, that gets ignored.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8456802 [details] [diff] [review]
proposed fix

Removing request until mkmelin addresses or responds to jcranmer's points.

Comment 3

[Thomas D. (:thomas8)]

Tentative UX comments (this is certainly tricky...)

- We need to find a sustainable solution for this, more so with an eye on bug 440377 (single-line input fields for multiple addresses). After that bug, it's even more crucial than now to distinct between comma as an address separator and comma inside display name.
- Even for current single-address per input field, we probably MUST keep quotes in UI around display names having special chars like commas. As Magnus says, otherwise (in current UI at least), there won't be any way for user to use and visually distinguish between these:
  - maillist, SingleRecipient <[e-mail]>
  - Surname, FirstName <[e-mail]>
Imagine real life scenarios e.g. Mailing List "Management", and single recipient having display name "Management, John <...>". 
'Surname, Firstname' as display name is presumably a frequent scenario in other locales like JP.
- Plus in the current single-address per input layout, we also allow entering multiple comma-separated addresses which must be handled correctly if mixed with display names having inner comma
- Examine how this interacts with "auto-complete to domain" where users can just enter "john" to autocomplete to [e-mail]

Tentative design guidelines
- Let's allow and preserve as many technically allowed character combinations as possible (standards compliance)
- Ensure that user can unambiguously enter mailing lists AND display names having inner commas
- Ensure that visual UI (after entering) still allows unambiguous distinction of  mailing lists and display names with comma
- Quotes "inside" a display name, as in «John "The Bomb" Smith», are certainly an edge case; we should support that according to standards if possible; if that requires forcing users to use \" for escaping "inner" quotes, than that's a necessary evil.

Comment 4

[:aceman]

(In reply to Joshua Cranmer [:jcranmer] from comment #1)
> I am extremely skeptical that the quotation mechanism you provide here is
> actually doing what you want it to do. Yes, you have a test that it displays
> in the compose window correctly, but that's not the real issue. I suspect
> that if you let it get out to the MIME message, you'd have:
> To: "\"Bond, James\"" <blah@blah>
> which is not what you want.

Then we probably need to remove the quotes again when MIME constructing the message source.
But we need a way to escape or quote the comma in addresses as long as the compose widget uses comma as a message separator.

OR do we switch to another less used character, e.g. semicolon (;) as Outlook does?

Comment 5

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #4)

> OR do we switch to another less used character, e.g. semicolon (;) as
> Outlook does?

No, we can't use semicolon as recipient separator because we'd break RFC conventions with that:

Bug 919953 - TB messes up RFC822 groups (named lists with semicolon,
                                         e.g. testlist: [e-mail], [e-mail]; )

Comment 7

[Thomas D. (:thomas8)]

Can we close this wfm?

• Following :jcranmer's r- of comment 1, I think there's nothing left to do here.
• Test case of comment 0 works: pasting lastname, firstname <[e-mail]>, foo <[e-mail] succeeds to create the correct addresses.
• Our internal mime parsers and the like now handle commas quite well, so this looks outdated.
• Forcing users into entering double quotes if we can succeed without doesn't look like a good idea wrt UX.
• Given that our frontend handling of recipients has completely changed with the introduction of recipient pills (bug 440377), any remaining problems should be handled in new, clean bugs based on current design.
• We now have a range of new problems on record around commas in display names which are arising from the dubious frontend design of autocompleting on comma.

Comment 8

[Magnus Melin [:mkmelin]]

Closing WONTFIX yes.