204437 - Format=flowed gobbles 1 space in indented lines

Status: RESOLVED INVALID

(MailNews Core :: Composition, defect)

Description

[Robin Whittle]

When a plain text message, with "format=flowed":

  Content-Type: text/plain; charset=us-ascii; format=flowed

is being displayed on the screen (when reading messages) then on any
line starting with 1 or more spaces, that line will be displayed with
one less space.

If the message lines are:

000
 111
  222
   333

then they will be displayed on screen as:

000
111
 222
  333

The same thing happens in Print and Print Preview.  However the lines
appear correctly in View Message Source.  (Editing the message as new
results in the correct indenting, but as noted below, there is another
bug which screws up what is sent and saved.)

Removing "format=flowed" from the Content-Type headers fixes the
problem. (For instance, I edit the message file on the IMAP server.)
Configuring Mozilla not to respond to "format=flowed" in the header 
solves the problem as well.

So the bug seems to be in the code which interprets "format=flowed"
plain text emails.

This bug hides the problem in the 1 year old bug
http://bugzilla.mozilla.org/show_bug.cgi?id=141983 
"Space added to indented line when sending or saving message" because it
hides the extra space.  But the extra space is in the messages
nonetheless and is seen by all non Mozilla mail readers.  The current 
bug seems to be younger than this "Space added" bug - because a year
ago, reading the messages with Mozilla did not hide this "Space added"
bug.

As noted in http://bugzilla.mozilla.org/show_bug.cgi?id=86607 "[RFE] UI
option for disabling format=flowed" the interpretation of
"format=flowed" in messages being read is on by default and there is no
user interface option for changing this.  (Likewise, the option for
sending plain text messages with "format=flowed" is on by default, with
no user interface option to change it.)

The workaround for both these bugs is to disable these features with the
following lines in user.js:

  pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
  pref("mailnews.display.disable_format_flowed_support", true);

For those who are more interested in using the program than chasing
bugs, I will document how I get Mozilla and Netscape 7 to do what I want
at:

  http://www.firstpr.com.au/web-mail/Mozilla-mail/

I observed this with Mozilla 2003050211 and Netscape 7.02 both on Win2k.
I assigned it to component "Composition" because I can't think of what
else to assign it to.

  - Robin

Comment 1

[Ben Bucksch (:BenB)]

Spec mandates that, code follows spec, invalid.

Please read RFC 2646 <http://asg.web.cmu.edu/rfc/rfc2646.html>.

Comment 2

[Robin Whittle]

As Ben writes, this is indeed what sending with "format=flowed" is meant to do.

  http://www.rfc-editor.org/rfc/rfc2646.txt

   If a space-stuffed message is received by an agent which handles
   Format=Flowed, the space-stuffing is reversed and thus the message
   appears unchanged.  An agent which is not aware of Format=Flowed will
   of course not undo any space-stuffing, thus Format=Flowed messages
   may appear with a leading space on some lines (those which start with
   a space, ">" which is not a quote indicator, or "From ").  Since
   lines which require space-stuffing rarely occur, and the aesthetic
   consequences of unreversed space-stuffing are minimal, this is not
   expected to be a significant problem.


Its still a problem for some users, as long as "format=flowed" is on by default, 
as is evident in bug 141983.  But this is not a problem in the implementation of 
sending with "format=flowed".

Comment 3

[Clark Breyman]

Seems that this bug creates problems for GNATS users who submit PR's by email. 
The field delimiter is \n><field name>:<value>. Flowing breaks the GNATS 
parser. Explicit selection of flowing and disabled default flowing of outbound 
mail would be my preference. Rgs, Clark