Composition: Pressing ENTER on BCC recipient with comma in display name creates a new recipient row of type "To" instead of "Bcc"
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(thunderbird_esr6871+ fixed, thunderbird71 fixed, thunderbird72 fixed)
People
(Reporter: pchoma2, Assigned: jorgk-bmo)
References
Details
User Story
Reproducible STR from comment 26 by Thomas D: STR 1. Write 2. Change TO to BCC 3. Type recipient: Doe, John <john@asdf.com> (important: display name with **comma**) 4. Press Enter (sic, do not click with mouse to select auto-complete result) Actual result: * TB creates a new recipient row of type "TO" (if the display name has a comma, AND you press Enter to confirm autocompletion). This bug. Expected result: * TB creates a new recipient row of type "BCC" For comparison: - Display names without comma will create "BCC" (ok) - Display name with comma, but selected with mouse click will create "BCC" (ok) **Related bug from comment 27 (could be fixed here):** TAB on a BCC recipient with comma in display name: Actually: [autocompletes and] creates "TO" (double wrong: shouldn't create new row, but if anything, it should be BCC) Expected: [autocomplete and] focus subject For comparison, tab on a recipient without comma will autocomplete and focus subject as intended.
Attachments
(5 files)
51.96 KB,
image/webp
|
Details | |
61.09 KB,
image/webp
|
Details | |
68.96 KB,
image/webp
|
Details | |
19.80 KB,
image/jpeg
|
Details | |
1.10 KB,
patch
|
mkmelin
:
review+
jorgk-bmo
:
approval-comm-beta+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
Comment 1•7 years ago
|
||
Assignee | ||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
Reporter | ||
Comment 4•7 years ago
|
||
Assignee | ||
Comment 5•7 years ago
|
||
Reporter | ||
Comment 6•7 years ago
|
||
Assignee | ||
Comment 7•7 years ago
|
||
Reporter | ||
Comment 8•7 years ago
|
||
Reporter | ||
Comment 9•7 years ago
|
||
Reporter | ||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Assignee | ||
Comment 12•7 years ago
|
||
Comment 13•7 years ago
|
||
Reporter | ||
Comment 14•7 years ago
|
||
Comment 15•7 years ago
|
||
Reporter | ||
Comment 16•7 years ago
|
||
Reporter | ||
Comment 17•7 years ago
|
||
Comment 18•6 years ago
|
||
(In reply to Peter Choma from comment #9)
Another observation: Started Thunderbird. Forwarded an existing email.
Changed initial To: line to Bcc:. As long as I used an exiting email
distribution list entry, Enter key caused next line to correctly change to
Bcc:. However as soon as I entered and exiting individual address line and
hit Enter, the next line remained as To: instead os switching to Bcc:
The only case where something like reporter's scenario can occur (apart from Contacts side bar, which was already mentioned), is if we take reporter's description at face value:
hit Enter, the next line remained as To: instead of switching to Bcc:
So probably there was a subsequent blank recipient in row 2 already, preset to TO (which can easily happen if you change the type of preceding row 1 to BCC only after pressing Enter for autocompletion).
I think there's a misunderstanding here. We never change/switch already existing recipient lines (blank or not) with a preset recipient type (and I don't think TB has ever done that, but would have to confirm for old versions). We only re-duplicate the current recipient type IF the next line doesn't exist yet, i.e. only IF the next line does NOT have a preset different recipient type already. Well, except when there's CSV lists that reporter is apparently talking about - they succeed to reduplicate BCC entries in spite of a subsequent preset, blank TO line.
Essentially there are three scenarios, and only one "fails" with reporter's expectations. I'll post annotated screenshots for the purpose of illustration.
Reporter (Peter Ch.), can you please comment if any of the screenshots describes your case. If not, please post your own step-by-step screenshots.
Comment 19•6 years ago
|
||
This is where it just works as expected, if you start on the last or only line and make that BCC before confirming with Enter.
Comment 20•6 years ago
|
||
This is where it allegedly fails. I think this is reporter's case. Otherwise it must involve Contacts Side bar.
Not sure if this could/should be improved.
Comment 21•6 years ago
|
||
The special case of CSV list entered into one recipient input. This works well in itself, but user might end up in scenario B if that's where he started from.
Reporter | ||
Comment 22•6 years ago
|
||
Alas, right now I do not have the time to read thru the three scenarios but I will try to do so this weekend.
Yes I can recreate this in ver 68.2.2. It is related to the name being present in my address book.
If I start with BCC and enter a brand new name, BCC propegates
If I enter an email list entry, BCC propegates
but if I choose some entries from my address book then the next line switches to to.
I create a new address book entry for myself and when I entered it, the next line was To; rather than BCC.
I suspect there is a length factor involved in the issue.
Reporter | ||
Comment 23•6 years ago
|
||
Added screen shot showing Bcc: Changing to To: after using name from my address book!
Reporter | ||
Comment 24•6 years ago
|
||
Scenario A - FAILS
Message --> New Message
Change "To:" to "BCC:"
Selected Choma, Peter-YAH from suggestion list
Result next line is To: and not BCC:
Scenario B - yes Get "To:" Line
Scenario C - noticed something interesting
Typed partial a name
- If I use a mouse click to select a suggested entry from my address book, then the next line becomes BCC:
- If I press the Enter key to select the suggested name, then the next line becomes TO: [I generally press enter to accept the suggested name!] Looks like this is where the problem lies.
Also interesting artifact. I capitalize the first letter of first and last name. If I start typing a name in lower case, and press enter key to accept the suggestion, then the suggest name begin with a lower case letter and continues with the casing of the rest of the name in the address book. It looks like the suggestion code only adds the missing suffix string to the currently typed code and does not replace it with the whole value in the address book.
To recreate (lowercase artifact) Message->New Message
type lowercase prefix string for some capitalized name in address book and when get a match, press Enter key. Happens on both To: and BCC: line. The string you type must match the prefix of the DIsplay Name in the address book.
Reporter | ||
Comment 25•6 years ago
|
||
Ran a few more experiments.
It looks like the bug is related to using the ENTER key to accept the initial suggested email user from my address book. If I use the keyboard arrow keys to step to another entry OR use the mouse to select any entry even the first entry, then the BCC properly propagates to the next line.
Using the ENTER key to select the initial user suggestion (based on chars entered on the current bcc: line) causes TO: to be used instead of BCC: on the next line.
Comment 26•6 years ago
•
|
||
str |
(In reply to Peter Ch from comment #24)
Scenario A - FAILS
Message --> New Message
Change "To:" to "BCC:"
Selected Choma, Peter-YAH from suggestion list
Result next line is To: and not BCC:
Thanks a lot Peter for your instant, now more precise feedback based on my detailed test cases. This has enabled me to track down your issue.
(In reply to Jorg K (GMT+2) from comment #12)
Can someone find a reproducible case and we can look into it.
Sure, just invite me to the party... ;-) Here we go:
STR
- Write
- Change TO to BCC
- Type recipient: Doe, John <john@asdf.com> (important: display name with comma)
- Press Enter (sic, do not click with mouse to select auto-complete result)
Actual result:
- TB creates a new recipient row of type "TO" (if the display name has a comma, AND you press Enter to confirm autocompletion). This bug.
Expected result:
- TB creates a new recipient row of type "BCC"
For comparison:
- Display names without comma will create "BCC" (ok)
- Display name with comma, but selected with mouse click will create "BCC" (ok)
Possible problem in code:
- Enter event probably checks for comma in recipient string, if found, tries to parse it as CSV. When there's a comma in display name but nothing to parse for CSV, we don't go back to that spot where we create another row of same type after a regular, single-recipient autocomplete lookup.
Lessons to learn from this bug:
- Precise, list-style STR are crucial. Let's not let reporters get away with "Enter an email address from one of my saved one" - we need to know the exact string, especially when it works for us but fails for reporter. I acknowledge this is easier to say with the benefit of hindsight, and it's part of the triage process to narrow down reproducable STR, but still - had we insisted to know the exact recipient string, or asked reporter to reproduce with our exact recipient string, lots of wild testing iterations in this bug could have been avoided. No blames, just a mental note for next time...
Updated•6 years ago
|
Updated•6 years ago
|
Comment 27•6 years ago
•
|
||
Related bug (could be fixed here):
TAB on a BCC recipient with comma in display name:
Actually: [autocompletes and] creates "TO" (double wrong: shouldn't create new row, but if anything, it should be BCC)
Expected: [autocomplete and] focus subject
For comparison, tab on a recipient without comma will autocomplete and focus subject as intended.
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 28•6 years ago
|
||
(In reply to Thomas D. from comment #26)
Sure, just invite me to the party... ;-)
You already have a standing (permanent) invitation ;-)
I can confirm this: Selecting a, b <c@d.com>
with enter either from auto-complete or just with enter if there was no auto-complete suggestion (like I don't have "Dow, John" in my address book) does strange things. Even worse: "a, b" <c@d.com>
.
Paul, from some light diversion from Calendar stuff, maybe you'd like to take a look. Or maybe Magnus who worked on the comma and semicolon stuff recently.
Comment 29•6 years ago
•
|
||
(In reply to Jorg K (GMT+2) from comment #28)
I can confirm this: Selecting
a, b <c@d.com>
with enter...
Even worse:"a, b" <c@d.com>
.
Yes, that's probably worse in the sense of "we should never let that comma trigger anything because it's in double quotes".
In terms of this bug, the result is the same.
I also checked for the rare case of comma in the local part, which is valid. As expected, that also triggers this bug, but we do separate multiple recipients correctly:
a, b <"c, d"@e.com>, f, g <h@j.com>
, upon pressing Enter, gets correctly parsed as:
a, b <"c, d"@e.com>
f, g <h@j.com>
... with a subsequent "TO" recipient (this bug).
Updated•6 years ago
|
Assignee | ||
Comment 30•6 years ago
•
|
||
I see you edited your comment. Yes, the "worse" is that the comma enclosed by quotes is used to split and that one quote ends up in one recipient, and the other one in another :/
Comment 31•6 years ago
•
|
||
(In reply to Jorg K (GMT+2) from comment #30)
I see you edited your comment. Yes, the "worse" is that the comma enclosed by quotes is used to split and that one quote ends up in one recipient, and the other one in another :/
Thanks. It doesn't split up wrongly for me using "a, b" <c@d.com> - any hints how to reproduce this?
Assignee | ||
Comment 32•6 years ago
|
||
any hints how to reproduce this?
Hmm, I'd like to know myself now. I saw "a
in one line and b" <c@d.com>
in the next. Now I can't reproduce it either. Anyway, display names with a comma, with or without quotes, seem to work OK, only that they change a Bcc to a To if enter is used to advance to the next line.
Ahh, I found it. Enter "a, b" <d.com>
- that plays up.
Comment 33•6 years ago
|
||
Probably you have the culprit right here: https://searchfox.org/comm-central/rev/2c6b74cbc1457670a7e89613baee908837d73799/mail/components/compose/content/addressingWidgetOverlay.js#441
But this thing is getting such a major overhaul in bug 440377, I don't think this particular edge case is very important to fix.
Comment 34•6 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #33)
But this thing is getting such a major overhaul in bug 440377, I don't think this particular edge case is very important to fix.
Agreed, shouldn't be a problem once we make the transition to the new UI.
Assignee | ||
Comment 35•6 years ago
|
||
Tested by entering
a, b <c@d.com>
and pressing enter.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 36•6 years ago
|
||
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/84b703945054
when creating a new row in the addressing widget, don't switch back to To: (analysis by :mkmelin). r=mkmelin
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Reporter | ||
Comment 37•6 years ago
|
||
-
If the code is being redesigned it would be very helpful to have a way to sort the email recipients by Last name, or display name, or email address. [Enhancement request]
-
Add a test case where you enter a lowercase prefix to select an email address from the address book that contains names where the first and lastname begins with an uppercase letters and make sure the lower case search string is replaced with the entire entry from the address book. Currently, there are random cases where the first letter is not replaced and the Bcc: name is displayed with an initial lowercase letter. Alas, I do not currently have an example.
Assignee | ||
Comment 38•6 years ago
|
||
TB 71 beta 3:
https://hg.mozilla.org/releases/comm-beta/rev/86baa2a8d9a13e900327125b2ed7a7041a181325
Assignee | ||
Comment 39•6 years ago
|
||
TB 68.3 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/b4f325aa139aaca2de81c20cbcf12c635e124e8a
Comment 40•6 years ago
•
|
||
(In reply to Jorg K (GMT+2) from comment #39)
TB 68.3 ESR:
https://hg.mozilla.org/releases/comm-esr68/rev/b4f325aa139aaca2de81c20cbcf12c635e124e8a
Thanks Jörg for fixing this one-liner immediately for the benefit of many users. Your hands-on approach is much appreciated and highly beneficial for Thunderbird.
(In reply to Peter Choma from comment #37)
- If the code is being redesigned it would be very helpful to have a way to sort the email recipients by Last name, or display name, or email address. [Enhancement request]
Please check if there's a bug for that, and file one if there isn't, then mark it as blocking bug 440377. 100% supported by me, sorting recipients in composition is long overdue, more so now when the default becomes a crowded collection of pills. Related, I'd also expect something like legacy view, which allows users to view pills in a single column or multi-column layout.
- Add a test case where you enter a lowercase prefix to select an email address from the address book that contains names where the first and lastname begins with an uppercase letters and make sure the lower case search string is replaced with the entire entry from the address book. Currently, there are random cases where the first letter is not replaced and the Bcc: name is displayed with an initial lowercase letter. Alas, I do not currently have an example.
If you have a reproducable test case, please file a bug. I tried, but couldn't reproduce.
Description
•