User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20101026 Firefox/3.6.12 GTB7.1 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 When writing plain text messages, a spurious space is inserted at the beginning of some lines, especially indented ones. This results in misaligned text. Reproducible: Always Steps to Reproduce: 1. Start a new message, 2. Write some test, indenting some lines, 3. Send the message to yourself, 4. Check the message source or read the message using a compliant MUA. Actual Results: Not indented Indented by one Indented by two From now on lines are not indented and this one actually is not. Expected Results: Not indented Indented by one Indented by two From now on lines are not indented and this one actually is not. If you look at the test message through the regular window, it looks like the Expected Results above. Thus, incoming text/plain messages are probably displayed in a garbled manner.
This WFM with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101110 Thunderbird/3.3a1pre in plain text mode composition. Have you tried -safe-mode (http://support.mozillamessaging.com/en-US/kb/Safe+Mode) ? How are you composing ?
(In reply to comment #1) > This WFM with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) > Gecko/20101110 Thunderbird/3.3a1pre in plain text mode composition. Did you check your message source? > Have you tried -safe-mode Yes > How are you composing ? Text/plain. I assume you tried with this setting. As a workaround, I've now set mailnews.send_plaintext_flowed false This way, the bug does not show and I can send what I type.
Space-stuffing is still incompatible in TB 6. By incompatible, I mean it adds spaces in an apparently unpredictable way. The spec says On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " MUST be space-stuffed. Other lines MAY be space-stuffed as desired. http://tools.ietf.org/html/rfc3676#section-4.4 It seems to me that adding a space to all unquoted lines would produce more consistent results when passing through mailers that alter the Content-Type.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
I cannot reproduce this. Can you still reproduce?
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #5) > I cannot reproduce this. > Can you still reproduce? Yes, using Icedove 38.8.0. I've kept mailnews.send_plaintext_flowed=false ever since. If I re-enable it, I obtain the same spurious spaces I obtained in 2010. Note that those spaces are only visible in source view (Ctrl-U) or with a different client. Don't you see them? Ale
I've come here via bug 1287126. Now, there are no spurious spaced inserted, as the original summary said. The fact is that certain lines are space stuffed according to http://tools.ietf.org/html/rfc3676#section-4.4 as the reporter has pointed out himself in comment #3. The extra spaces are not shown when the message is displayed. Sorry about other clients not getting it right. The real problem is, that if such a draft is edited, the space stuffing is not removed before placing the content into the compose window. Sorry for hijacking this bug ;-)
Ignore what I said, partly. The space stuffing is correct. When editing such a draft in TB 31, the extra spaces get removed. So TB 31 doesn't have the problem I described in comment #8. I'm changing the subject back and I'm marking the bug invalid since the extra spaces are correct according to RFC 3676. The "edit draft" problem will be treated in bug 1287126 since it's a recent regression.