707778 - When sending email, Thunderbird adds a space character to lines starting with whitespace

Status: RESOLVED DUPLICATE of bug 608514

(Thunderbird :: Message Compose Window, defect)

Description

[Christian]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111108090024

Steps to reproduce:

I use plain-text email, and I often compose messages that have bullet points, like this one:

- Here's a bullet point that I manually
  indent in subsequent lines to line up.


Actual results:

Thunderbird decides to tuck an additional space character on to the lines already starting with whitespace. So basically, what I sent like this ...

-<spc>Here's a bullet point that I manually
<spc><spc>indent in subsequent lines to line up.

... turns into this, in both the sent message and the corresponding received one:

-<spc>Here's a bullet point that I manually
<spc><spc><spc>indent in subsequent lines to line up.



Expected results:

Thunderbird should keep my line-start whitespace as I intended it.

Comment 1

[rsx11m]

See bug 608514 which seems to apply here, i.e., in plain-text composition mode and without format=flowed disabled, this should be the standard-compliant encoding.

Some e-mail clients (like Outlook) ignore format-flowed and show the leading space as is present in the encoding, though they are not supposed to.

In Edit > Preferences > Advanced > General > Config Editor, toggle the preference mailnews.send_plaintext_flowed to "false" and you should see the space removed.

Thunderbird displays either encoding (with or without flowed format) as expected.

Comment 2

[Christian]

Thanks, you're right regarding the adjustment to mailnews.send_plaintext_flowed, it helped.

I suppose when you say "as expected" you mean the extra space is expected when send_plaintext_flowed is true, because I do see the extra space both in sent and received messages in Thunderbird.

Comment 3

[rsx11m]

Yes, the display in Thunderbird itself is correct with the leading space removed. Since there doesn't seem to be a bug, I'm closing this report as a duplicate.