User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36 Steps to reproduce: I copy the following list and I paste (with spaces and all the rest in TB31.5) email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Furthermore See here email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org Actual results: In TB 31.5 it creates the following recipients from that list: email@example.com ,firstname.lastname@example.org ,email@example.com ,firstname.lastname@example.org According to me this is a bug introduced from the v.24 to the v. 31 because the origin of data is the same but TB interprets comma and line in a different way in the new version 31.xx . Furthermore each blank line TB 31.xx and later puts a comma So you obtain the following recipients email@example.com firstname.lastname@example.org ,email@example.com firstname.lastname@example.org so ,email@example.com comes out wrongly. Expected results: TB 24.6 all the recipients are considered normally and it creates a list of 4 recipients without commas. According to me this is a bug introduced from the v.24 to the v. 31 because the origin of data is the same but TB interprets comma and line in a different way in the new version 31.xx .
I would not consider this a bug. We could consider it as an enhancement. STR 1) From external data source like text editor or word processor, copy the following list of recipients (having comma AND line breaks): firstname.lastname@example.org, email@example.com, firstname.lastname@example.org 2) Write a new msg 3) Paste recipients list into single recipient input field and look at the result in the single line (sic!) 4) press Enter and look at recipients Actual result: 3) TB replaces the linebreaks with commas (which is good for linebreak-separated lists), but the net result in this particular case is double commas: email@example.com,,firstname.lastname@example.org,,email@example.com 4) After splitting, the extra commas are preserved (should they?), creating malformed recipients: firstname.lastname@example.org ,email@example.com ,firstname.lastname@example.org Fwiw, these are then "correctly" quoted before sending: To: email@example.com, ",foo2"@asdf.com, ",foo3"@asdf.com Expected result I wonder if we could/should handle this edge case better at some stage. Not exactly sure how, given that ",foo1"@asdf.com is actually a valid address, and it seems we allow simplified entering of that as ,firstname.lastname@example.org and then do the quoting later, same for display names.
Tentative solution: I believe quoted local parts in email addresses are extremely rare, more so having a leading comma: ",foo2"@asdf.com is valid, but doesn't look like a real life scenario. So perhaps we could expect those who want those edge cases to use correct syntax with double quotes, and err in favor of the much more likely scenario of slightly "malformed" lists currently causing double commas: Where we replace line breaks with commas, we should instead use a regular expression with this effect: Replace all linebreaks and any preceeding whitespace and preceeding commas with just a single comma: email@example.com/n (linebreak only) firstname.lastname@example.org email@example.com /n (linebreak with preceding whitespace) firstname.lastname@example.org email@example.com,/n (linebreak with preceding comma) firstname.lastname@example.org email@example.com, /n (linebreak with preceding comma and whitespace) firstname.lastname@example.org -> email@example.com, firstname.lastname@example.org So user who really need the comma in the local part would have to quote it correctly: email@example.com/n ",foo2"@bar.com Which I believe is the more likely syntax anyway because if you really use such extremely extraordinary addresses, chances are you'll list them correctly quoted because they will break otherwise.
Toni, could you explain why you're using lists with 2 separators, commas AND line breaks?
xref bug 1087989 (and iirc some other, that "empty" recipients should just be ignored)
and ??? did somebody try to solve this bug ?
(In reply to toni from comment #6) > and ??? did somebody try to solve this bug ? and ??? did YOU answer my question in comment 4? (In reply to Thomas D. from comment #4) > Toni, could you explain why you're using lists with 2 separators, commas AND > line breaks? did you read bug 1087989 pointed by comment 5, where a workaround for your scenario is offered? Bug 1087989 Comment 2 > changing editor.singleLine.pasteNewlines from 4 to 3 helped to solve the problem! Did you understand from my comment 2 that this NOT a bug, but a request for feature enhancement?
Yes but version 24 eats everything without confusion; now I am using only line separation and not comma but the issue remains and malformed recipients still appear I can't understand why changing features already working ! So I keep using a very old version 24. I didn't understand clearly the workaround