958247 - Multipart emails with Format=Flowed plain text should have leading space character (from space-stuffing) removed when opened for editing

Status: UNCONFIRMED

(Thunderbird :: Message Compose Window, defect)

Description

[Vincent Yu]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Steps to reproduce:

First, save the following block of text as a plain text draft:

0123456789
no space
 1 space
  2 spaces
0123456789

Now close the compose window, then re-open the draft for editing.

(To reproduce the bug, Thunderbird should be set up to use Format=Flowed for outgoing emails and to be compliant with RFC 3676 [1] for incoming emails, which are both the default setting. That is, have mailnews.send_plaintext_flowed=true and mailnews.display.disable_format_flowed_support=false.)


Actual results:

The compose window shows the following text:

0123456789
no space
  1 space
   2 spaces
0123456789

Note the extra space character prepended to the third and fourth lines.


Expected results:

The compose window should show the following text:

0123456789
no space
 1 space
  2 spaces
0123456789

Note that there is no extra space character prepended to the third and fourth lines.

This bug only appears when a Format=Flowed draft is *opened for editing*. There are no issues with saving, sending, or reading a Format=Flowed email. In particular, Thunderbird correctly prepends a space character to the third and fourth lines (i.e., space-stuffs) when saving and sending Format=Flowed emails (see RFC 3676 [1], Section 4.4) and Thunderbird also correctly removes the space-stuffing when reading such emails, but Thunderbird is incorrectly neglecting to remove the space-stuffing when opening such an email for editing.

The main usability issue with this bug is that an extra space character is prepended to every space-indented line whenever a draft is saved, closed, then re-opened. These extra spaces are a pain to remove because we cannot use an automated search-and-replace function (as that would also impact the original space indentation).

I do not have SeaMonkey available to test this, but if this bug also appears there, then I think this report should be moved to MailNews Core Composition.

[1]: https://tools.ietf.org/html/rfc3676

Comment 1

[Vincent Yu]

My apologies, but I just discovered that I did not include enough steps to reproduce the bug in my original report. The bug only appears when the Content-Transfer-Encoding is quoted-printable [1]. Quote-printable is not enabled by default, but is enabled when S/MIME [2] or OpenPGP/MIME [3] is used. The behavior I reported still looks like a bug to me, but I am going to look through the RFCs to check if there is a good reason for the reported behavior when quoted-printable, S/MIME or OpenPGP/MIME is used. If I find something, I will update this report.

[1]: https://tools.ietf.org/html/rfc2045
[2]: https://tools.ietf.org/html/rfc5751
[3]: https://tools.ietf.org/html/rfc3156

Comment 2

[Vincent Yu]

I've figured out that the bug appears only when the multipart media type is used (my last comment about quoted-printable is not correct). That is, the bug appears only when all of the following conditions are satisfied:
  – The email uses the multipart media type in MIME (see RFC 2046 [1], Section 5.1).
  – The email is opened for editing (not for reading).
  – The email header includes "Content-Type: text/plain; format=flowed" (i.e., it is a plain-text email with Format=Flowed).

To reproduce the bug, follow the instructions in my original report, but add an attachment to the draft before saving it. That should be sufficient to reproduce the bug.

A temporary workaround is to make sure that drafts do not use the multipart media type. This entails not adding any attachments and not enabling the S/MIME extension.

For some reason, Thunderbird correctly removes the Format=Flowed space-stuffing when a non-multipart email is opened for editing, but incorrectly neglects to remove the Format=Flowed space-stuffing when a multipart email is opened for editing.

I have edited the bug summary and replaced it with a more accurate description.

[1]: https://tools.ietf.org/html/rfc2046