If the recipient name includes a comma, pressing enter or tab in the field will split the name of the recipient into two lines IF the field is being edited. Example: 1. Type the recipient name into the "To" field in compose window. This is often auto completed so in practice the owner of the e-mail address determines how his/her name will look like. E.g. "Smith, John" <firstname.lastname@example.org> 2. Move focus elsewhere, for instance the next field by pressing enter or tab. Move the focus back to the same field. 2. Press tab or enter. 3. The result is two lines: Smith < > John <email@example.com> Happens every time if auto-complete has the time to look up for addresses from its database. Highly annoying. The only way to avoid this (and sometimes there is no way) is to use the mouse to change the focus. If my memory serves me right, this behaviour was first introduced in Seamonkey 2.26.
I see this too in 2.29 on both Linux and Windows, Thunderbird 31.1.1 isn't affected (corresponding to SM 2.28, thus after the stated regression window). Clearly, the line is now parsed during focus changes and the comma resolved as delimiter for multiple addresses (where accepting an empty "< >" address part in itself could be considered a bug), or previously were enclosed in '"' quotes and thus not split.
Component: Composer → MailNews: Composition
OS: Linux → All
Hardware: x86 → All
There seems to be a more general issue when composing new mails using addresses with realnames that contain commas. From bug 1088975 we can see that this principally also affects Thunderbird. With SM 2.30, I did a few tests: 1. When using the context menu on the From: header in the message or preview pane and selecting "compose mail to", a mail address containing a comma gets split in two recipients as described above. This is not related to RFC2047 encoding, it just needs a comma in the realname. Using the reply button however works correctly. 2. When composing a new mail, a realname containing a comma causes the same bug under some, but not all circumstances. The bug is perfectly reproducible here if the complete recipient address is entered manually in the format "surname, name <firstname.lastname@example.org>" (without the quote characters) - then the address is erroneously split up in two fields as soon as TAB or ENTER are hit. 3. When composing a new mail and picking the recipients address (also containing the comma in the realname) from the address books, the bug does not always show. It seems to depend on the number of hits from the search, and maybe some more parameters. For testing, I created an address book entry for "Reh, Tilmann" with the mail address <email@example.com> which in fact is the only address with that TLD. Now in the compose dialog, when I enter "lokal" in the To: field, the address gets split on ENTER, but not always on TAB. However, when using TAB, sometimes the previously (!) entered and (until then correct) address also gets mangled. On the other hand, if there is more than one match and you pick the address by cursor keys, it seemingly works correct: I enter "tilmann", then pick the comma-type entry, and press ENTER or TAB - and the address is taken correctly. If I select that entry by mouse click, it is also taken correctly - but then, as soon as ENTER or TAB is entered to proceed to the subject entry, it's mangled again. This does not happen if the subject field also is selected by mouse click, not by keyboard.
Note this was fixed in TB in bug https://bugzilla.mozilla.org/show_bug.cgi?id=966053
Created attachment 8556061 [details] [diff] [review] Patch v1.0 Port Thunderbird fix.
Comment on attachment 8556061 [details] [diff] [review] Patch v1.0 Port Thunderbird fix. [Triage Comment] r/a=me
Attachment #8556061 - Flags: superreview?(mnyromyr) → superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-seamonkey2.32: --- → fixed
status-seamonkey2.33: --- → fixed
status-seamonkey2.34: --- → fixed
status-seamonkey2.35: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.35
You need to log in before you can comment on or make changes to this bug.