609908 - Spurious spaces inserted in test messages with mailnews.send_plaintext_flowed true

Status: RESOLVED INVALID

(MailNews Core :: Composition, defect)

Description

[Alessandro Vesely]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 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:1.9.2.12) 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.

Comment 1

[Ludovic Hirlimann [:Usul]]

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 ?

Comment 2

[Alessandro Vesely]

(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.

Comment 3

[Alessandro Vesely]

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.

Comment 4

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 5

[Wayne Mery (:wsmwk)]

I cannot reproduce this.
Can you still reproduce?

Comment 6

[Alessandro Vesely]

(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

Comment 8

[Jorg K (CEST = GMT+2)]

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 ;-)

Comment 9

[Jorg K (CEST = GMT+2)]

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.