65 bytes, text/plain
567 bytes, text/plain
I noticed this when I sent a mail with Mozilla from my Windows NT workstation to my Unix account and read the message with Pine. All the lines in my signature that begins with a space, somehow got an extra space. For example, a signature like this: -- one two three Turns out like this: -- one two three Strangely, when I read the test message with Mozilla, there's nothing wrong with the signature ;) The extra space doesn't turn out in the message composition either.
I see this on linux trunk 2000110908. Confirming, OS -> ALL.
*** Bug 63064 has been marked as a duplicate of this bug. ***
*** Bug 74109 has been marked as a duplicate of this bug. ***
*** Bug 73595 has been marked as a duplicate of this bug. ***
*** Bug 119660 has been marked as a duplicate of this bug. ***
15 years ago
*** This bug has been marked as a duplicate of 114620 ***
oops. wrong direction.
*** Bug 149656 has been marked as a duplicate of this bug. ***
*** Bug 114620 has been marked as a duplicate of this bug. ***
15 years ago
*** Bug 170879 has been marked as a duplicate of this bug. ***
should be a dup of bug 112986 *** This bug has been marked as a duplicate of 112986 ***
*** Bug 216781 has been marked as a duplicate of this bug. ***
This bug is not a duplicate of 112986. That bug relates to 'drafts.' I experience this bug still, and I am not using drafts. Also, I don't really see this as a 'minor' bug -- this bug is changing the text of emails that are sent with Mozilla. Spacing matters in many contexts. I have some examples, as I am able to monitor incoming email on my own SMTP server, and can absolutely show the spaces being added when the message is sent. First I will post the text of the message I sent, including a test signature that also shows alignment problems (since someone in another bug thread asked me to test that also). Then I will post the full transaction that I could see on my SMTP server while receiving this message. I did not save this email as a draft, nor select 'send later.' I just wrote it and sent it immediately. When I view the message in Mozilla after I get it back from my SMTP server, it appears as I sent it exactly, no spacing problems. However, when I 'view source' on the message, extra spaces can be seen, as well as when I view the message with another email client, like Outlook Express.
Created attachment 130123 [details] This is the text of the message as sent immediately through thunderbird
Created attachment 130124 [details] This is the client/server transcript of the receipt of my message at my SMTP server
Reopening due to recent identical bug reports - 208235 and 216781. The "extra" space disappearing again is covered separately in bug 215068. Seeking a testcase reproducible on any installation.
*** Bug 208235 has been marked as a duplicate of this bug. ***
I created an email to myself with the text: ABCD EFGH The received copy of that email appeard to be normal when viewed in Mozilla mail. I then created an email to myself with the text: ABCD EFGH IJKL MNOP The second email came back to me as: ABCD EFGH IJKL MNOP
Still see this problem? I don't see this on windows version 3.0a1pre (2008032302)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051101 SeaMonkey/2.0a1pre I don't use pre-written signatures, but until recently I used to see this in the body of plaintext email: lines beginning with a space used to come back off-by-one when reading, so that /* * a three-piece C comment */ would come back with the second and third lines misaligned by one column by respect to the first one. However, with the above-mentioned nightly (yesterday's: I've seen that today's has just been publoished but I haven't yet downloaded it) I cannot reproduce the error. Shopik, can _you_ reproduce it?
The bug still appears daily with version 18.104.22.168 (20080421) in both mail body and signature.
(In reply to comment #22) > The bug still appears daily with version 22.214.171.124 (20080421) in both mail body > and signature. > That's a Branch build -- changing Version accordingly, since according to comment #20 and comment #21 the bug is apparently WFM on Trunk.
Thanks for the update, which reminded me that I had retested this yesterday and found that it fails thunderbird trunk. I wasn't able to see it displaying the resulting message unless I used view source. so 1.8 is not accurate. Perhaps this should be changed to Thunderbird, vers=unspec?
I tested this with several messages, and among others, one which I typed as zero one two three It was displayed the same, but View Source showed one additional space at the start of all lines except line zero. That additional space (which I didn't type) was also not displayed so in this case there is no bug. I have mailnews.display.disable_format_flowed_support and mailnews.send_plaintext_flowed both set at their default (false and true, respectively). I suspect that this might perhaps influence what I see. Kevin, what do you see in the Config Editor (accessed from a button in the "Advanced" preferences) when you type "flowed", without quotes, in the Filter box?
(In reply to comment #25) > I tested this with several messages, and among others, one which I typed as > > zero > one > two > three > > It was displayed the same, but View Source showed one additional space at the > start of all lines except line zero. That additional space (which I didn't > type) was also not displayed so in this case there is no bug. But it is in the underlying data it may affect searches. And also the format of replies by author and recipients. I also have those default settings.
Bingo! If I send mail to myself _with_ format-flowed and display it _without_ format-flowed, the additional space is displayed, which, I think, is not a bug but a result of inconsistent user settings. I'm awaiting Kevin's reply... (In reply to comment #26) > But it is in the underlying data it may affect searches. And also the format of > replies by author and recipients. > > I also have those default settings. > I don't know about searches, but when I reply to that email, on all lines the first nonspace follows immediately the "> " quote marker, which may be a bug but not this bug.
P.S. I seem to remember that in format-flowed format, one space (not two) at the start of a source line means that this line was wrapped and should be appended to the previous source line, while two or more spaces mean that there is a line break folowed by (n-1) spaces. Can anyone find back the relevant RFC?
Tony, these are settings: mailnews.display.disable_format_flowed_support default boolean false mailnews.send_plaintext_flowed default boolean true
I just tried the one-two-three example from above: one two three shows both in my 'Sent' and 'Inbox' as: one two three But the source view of both shows the original: one two three So now it is only a display bug in Thunderbird?
(In reply to comment #30) > I just tried the one-two-three example from above: > one > two > three > shows both in my 'Sent' and 'Inbox' as: > one > two > three > But the source view of both shows the original: > one > two > three > So now it is only a display bug in Thunderbird? > Hm, I'm not sure. From the above, it looks like a bug in Thunderbird 2 (and maybe SeaMonkey 1.1 -- both are based on Gecko 1.8.1) which was corrected in Thunderbird 3 (and SeaMonkey 2, both based on Gecko 1.9); but I may have misunderstood what Wayne was saying.
my very vague recollection is there was a change from TB2 to TB3. no idea of bug#. I haven't tried TB2, so the only think I was trying to say is trunk is still flawed. Leaving disposition to you all, gotta take myself off this bug
I think you're discussing bug 411901.
(In reply to comment #33) > I think you're discussing bug 411901. > In bug 411901, the problem was that mailnews.display.disable_format_flowed_support was TRUE, causing the mail to be displayed as received, with the "space-stuffing" added on sending as part as format=flowed accordingf to RFC 2646 and RFC 3676. Here, Kevin said in comment #29 that his setup had format-flowed on both sending and receiving, so we are not in the same circumstances as bug 411901 comment #12, where the latter bug was RESOLVED INVALID.
He's also using 2.0, which is quite irrelevant at the moment given how much has changed since then. Kevin: please retry with trunk (or 3.0alpha1, will be out shortly).
I'm completely unclear what the problem here is. I suspect the reporters may be unclear on the symptoms. Nobody reporting the bug mentions how the mail in question was composed, which is key. If the mail is composed in the plain-text editor, and with the wrap column set to a nonzero value, I don't think there are any actual problems with f=f composition, transmission, or display, in TB2 or TB3. If the mail is composed in HTML but sent as plain-text, or if the mail is composed as plain-text but with the wrap column set to zero, there are known issues in 2.x, many of which are addressed in 3.x thanks to a series of patches from late last year -- in particular, bug 125928, bug 215068, bug 261467. The original poster complained because he was using pine (c. 2000) which did not (then, at least) handle f=f. I don't know if pine deals with it now, altho it should; lots of modern mail clients display it properly and some send it out properly. Kevin, if you can still reproduce whatever your problem was with a current trunk build (or after 3.0 is released), then please open a new bug for it -- since you state the problem you saw was in the message body, your issue does not belong in this sig-specific bug. If you open the new bug, provide all the details mentioned above in a clear set of steps to reproduce.