57800 - The lines in signature file gets an extra space if the line begins with one.

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[viipale+bugzilla]

I noticed this when I sent a mail with Mozilla from my Windows NT workstation
to my Unix account and read the message with Pine. All the lines in my
signature that begins with a space, somehow got an extra space.
For example, a signature like this:

--
one
 two
  three

Turns out like this:

--
one
  two
   three

Strangely, when I read the test message with Mozilla, there's nothing wrong
with the signature ;) The extra space doesn't turn out in the message 
composition either.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see this on linux trunk 2000110908.  Confirming, OS -> ALL.

Comment 2

[Azrael AOD]

*** Bug 63064 has been marked as a duplicate of this bug. ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

*** Bug 74109 has been marked as a duplicate of this bug. ***

Comment 4

[Keyser Sose]

*** Bug 73595 has been marked as a duplicate of this bug. ***

Comment 5

[Boris Zbarsky [:bzbarsky]]

*** Bug 119660 has been marked as a duplicate of this bug. ***

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 114620 ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

oops.  wrong direction.

Comment 8

[Boris Zbarsky [:bzbarsky]]

*** Bug 149656 has been marked as a duplicate of this bug. ***

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 114620 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 170879 has been marked as a duplicate of this bug. ***

Comment 11

[Jean-Francois Ducarroz]

should be a dup of bug 112986

*** This bug has been marked as a duplicate of 112986 ***

Comment 12

[Vedran Miletic]

v

Comment 13

[Thomas Winzig]

*** Bug 216781 has been marked as a duplicate of this bug. ***

Comment 14

[Thomas Winzig]

This bug is not a duplicate of 112986. That bug relates to 'drafts.' I
experience this bug still, and I am not using drafts. Also, I don't really see
this as a 'minor' bug -- this bug is changing the text of emails that are sent
with Mozilla. Spacing matters in many contexts.

I have some examples, as I am able to monitor incoming email on my own SMTP
server, and can absolutely show the spaces being added when the message is sent.

First I will post the text of the message I sent, including a test signature
that also shows alignment problems (since someone in another bug thread asked me
to test that also). 

Then I will post the full transaction that I could see on my SMTP server while
receiving this message. 

I did not save this email as a draft, nor select 'send later.' I just wrote it
and sent it immediately.

When I view the message in Mozilla after I get it back from my SMTP server, it
appears as I sent it exactly, no spacing problems. However, when I 'view source'
on the message, extra spaces can be seen, as well as when I view the message
with another email client, like Outlook Express.

Comment 15

[Thomas Winzig]

Attachment: This is the text of the message as sent immediately through thunderbird

Comment 16

[Thomas Winzig]

Attachment: This is the client/server transcript of the receipt of my message at my SMTP server

Comment 17

[Joe Infla]

Reopening due to recent identical bug reports - 208235 and 216781.  The "extra"
space disappearing again is covered separately in bug 215068.  Seeking a
testcase reproducible on any installation.

Comment 18

[Joe Infla]

*** Bug 208235 has been marked as a duplicate of this bug. ***

Comment 19

[Michael W. Burden]

I created an email to myself with the text:
ABCD
 EFGH
The received copy of that email appeard to be normal
when viewed in Mozilla mail.


I then created an email to myself with the text:
ABCD EFGH
 IJKL MNOP

The second email came back to me as:
ABCD EFGH
  IJKL MNOP

Comment 20

[Wayne Mery (:wsmwk)]

Still see this problem?

I don't see this on windows version 3.0a1pre (2008032302)

Comment 21

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051101 SeaMonkey/2.0a1pre

I don't use pre-written signatures, but until recently I used to see this in the body of plaintext email: lines beginning with a space used to come back off-by-one when reading, so that

/*
 * a three-piece C comment
 */

would come back with the second and third lines misaligned by one column by respect to the first one.

However, with the above-mentioned nightly (yesterday's: I've seen that today's has just been publoished but I haven't yet downloaded it) I cannot reproduce the error.

Shopik, can _you_ reproduce it?

Comment 22

[Kevin Ivory]

The bug still appears daily with version 2.0.0.14 (20080421) in both mail body and signature.

Comment 23

[Tony Mechelynck [:tonymec]]

(In reply to comment #22)
> The bug still appears daily with version 2.0.0.14 (20080421) in both mail body
> and signature.
> 

That's a Branch build -- changing Version accordingly, since according to comment #20 and comment #21 the bug is apparently WFM on Trunk.

Comment 24

[Wayne Mery (:wsmwk)]

Thanks for the update, which reminded me that I had retested this yesterday and found that it fails thunderbird trunk. I wasn't able to see it displaying the resulting message unless I used view source. 

so 1.8 is not accurate. Perhaps this should be changed to Thunderbird, vers=unspec?

Comment 25

[Tony Mechelynck [:tonymec]]

I tested this with several messages, and among others, one which I typed as

zero
 one
  two
   three

It was displayed the same, but View Source showed one additional space at the start of all lines except line zero. That additional space (which I didn't type) was also not displayed so in this case there is no bug.

I have mailnews.display.disable_format_flowed_support and mailnews.send_plaintext_flowed both set at their default (false and true, respectively). I suspect that this might perhaps influence what I see. Kevin, what do you see in the Config Editor (accessed from a button in the "Advanced" preferences) when you type "flowed", without quotes, in the Filter box?

Comment 26

[Wayne Mery (:wsmwk)]

(In reply to comment #25)
> I tested this with several messages, and among others, one which I typed as
> 
> zero
>  one
>   two
>    three
> 
> It was displayed the same, but View Source showed one additional space at the
> start of all lines except line zero. That additional space (which I didn't
> type) was also not displayed so in this case there is no bug.

But it is in the underlying data it may affect searches. And also the format of replies by author and recipients.

I also have those default settings.

Comment 27

[Tony Mechelynck [:tonymec]]

Bingo! If I send mail to myself _with_ format-flowed and display it _without_ format-flowed, the additional space is displayed, which, I think, is not a bug but a result of inconsistent user settings. I'm awaiting Kevin's reply...

(In reply to comment #26)
> But it is in the underlying data it may affect searches. And also the format of
> replies by author and recipients.
> 
> I also have those default settings.
> 

I don't know about searches, but when I reply to that email, on all lines the first nonspace follows immediately the "> " quote marker, which may be a bug but not this bug.

Comment 28

[Tony Mechelynck [:tonymec]]

P.S. I seem to remember that in format-flowed format, one space (not two) at the start of a source line means that this line was wrapped and should be appended to the previous source line, while two or more spaces mean that there is a line break folowed by (n-1) spaces. Can anyone find back the relevant RFC?

Comment 29

[Kevin Ivory]

Tony, these are settings:
mailnews.display.disable_format_flowed_support default boolean false
mailnews.send_plaintext_flowed                 default boolean true

Comment 30

[Kevin Ivory]

I just tried the one-two-three example from above:
one
 two
  three
shows both in my 'Sent' and 'Inbox' as:
one
two
 three
But the source view of both shows the original:
one
 two
  three
So now it is only a display bug in Thunderbird?

Comment 31

[Tony Mechelynck [:tonymec]]

(In reply to comment #30)
> I just tried the one-two-three example from above:
> one
>  two
>   three
> shows both in my 'Sent' and 'Inbox' as:
> one
> two
>  three
> But the source view of both shows the original:
> one
>  two
>   three
> So now it is only a display bug in Thunderbird?
> 

Hm, I'm not sure. From the above, it looks like a bug in Thunderbird 2 (and maybe SeaMonkey 1.1 -- both are based on Gecko 1.8.1) which was corrected in Thunderbird 3 (and SeaMonkey 2, both based on Gecko 1.9); but I may have misunderstood what Wayne was saying.

Comment 32

[Wayne Mery (:wsmwk)]

my very vague recollection is there was a change from TB2 to TB3. no idea of bug#. 

I haven't tried TB2, so the only think I was trying to say is trunk is still flawed. Leaving disposition to you all, gotta take myself off this bug

Comment 33

[Magnus Melin [:mkmelin]]

I think you're discussing bug 411901.

Comment 34

[Tony Mechelynck [:tonymec]]

(In reply to comment #33)
> I think you're discussing bug 411901.
> 

In bug 411901, the problem was that mailnews.display.disable_format_flowed_support was TRUE, causing the mail to be displayed as received, with the "space-stuffing" added on sending as part as format=flowed accordingf to RFC 2646 and RFC 3676.

Here, Kevin said in comment #29 that his setup had format-flowed on both sending and receiving, so we are not in the same circumstances as bug 411901 comment #12, where the latter bug was RESOLVED INVALID.

Comment 35

[Magnus Melin [:mkmelin]]

He's also using 2.0, which is quite irrelevant at the moment given how much has changed since then. Kevin: please retry with trunk (or 3.0alpha1, will be out shortly).

Comment 36

[Mike Cowperthwaite]

I'm completely unclear what the problem here is.  I suspect the reporters may be unclear on the symptoms.  Nobody reporting the bug mentions how the mail in question was composed, which is key.

If the mail is composed in the plain-text editor, and with the wrap column set to a nonzero value, I don't think there are any actual problems with f=f composition, transmission, or display, in TB2 or TB3.

If the mail is composed in HTML but sent as plain-text, or if the mail is composed as plain-text but with the wrap column set to zero, there are known issues in 2.x, many of which are addressed in 3.x thanks to a series of patches from late last year -- in particular, bug 125928, bug 215068, 
bug 261467.

The original poster complained because he was using pine (c. 2000) which did not (then, at least) handle f=f.  I don't know if pine deals with it now, altho it should; lots of modern mail clients display it properly and some send it out properly.

Kevin, if you can still reproduce whatever your problem was with a current trunk build (or after 3.0 is released), then please open a new bug for it -- since you state the problem you saw was in the message body, your issue does not belong in this sig-specific bug.  If you open the new bug, provide all the details mentioned above in a clear set of steps to reproduce.