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

RESOLVED WORKSFORME

Status

MailNews Core
Composition
P3
minor
RESOLVED WORKSFORME
17 years ago
9 years ago

People

(Reporter: viipale+bugzilla, Unassigned)

Tracking

({polish})

1.8 Branch
x86
All
polish
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
I see this on linux trunk 2000110908.  Confirming, OS -> ALL.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All

Comment 2

17 years ago
*** Bug 63064 has been marked as a duplicate of this bug. ***
QA Contact: esther

Updated

17 years ago
Severity: normal → minor
Keywords: polish, ui
*** Bug 74109 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
*** Bug 73595 has been marked as a duplicate of this bug. ***
*** Bug 119660 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Component: Mail Back End → Composition
QA Contact: esther
Blocks: 112986

*** This bug has been marked as a duplicate of 114620 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
oops.  wrong direction.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 149656 has been marked as a duplicate of this bug. ***
*** Bug 114620 has been marked as a duplicate of this bug. ***
Blocks: 153807
*** Bug 170879 has been marked as a duplicate of this bug. ***
should be a dup of bug 112986

*** This bug has been marked as a duplicate of 112986 ***
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 12

14 years ago
v
Status: RESOLVED → VERIFIED

Comment 13

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

Comment 14

14 years ago
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

14 years ago
Created attachment 130123 [details]
This is the text of the message as sent immediately through thunderbird

Comment 16

14 years ago
Created attachment 130124 [details]
This is the client/server transcript of the receipt of my message at my SMTP server

Comment 17

14 years ago
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.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 18

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

Comment 19

13 years ago
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
Product: MailNews → Core

Comment 20

10 years ago
Still see this problem?

I don't see this on windows version 3.0a1pre (2008032302)
Assignee: mscott → nobody
Status: REOPENED → NEW
QA Contact: esther → composition
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

10 years ago
The bug still appears daily with version 2.0.0.14 (20080421) in both mail body and signature.
(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.
Version: Trunk → 1.8 Branch

Comment 24

10 years ago
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?
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

10 years ago
(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.

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

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

Comment 30

10 years ago
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?
(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

10 years ago
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

10 years ago
I think you're discussing bug 411901.
(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

10 years ago
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

10 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago10 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.