347074 - message display: missing first space, when lines begin with spaces

Status: RESOLVED DUPLICATE of bug 261467

(Thunderbird :: Mail Window Front End, defect)

Description

[Chris Chen]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.0.4) Gecko/20060602 Firefox/1.5.0.4
Build Identifier: thunderbird-1.5.0.4.en-US.solaris2.8-sparc-gtk1.tar.bz2

When a message (2 lines) is sent like below:

---
 one space before
1234
---

One gets:

---
one space before
1234
---


The first space in the " one space before" is always
trimmed off.  But, if one look at the message source
view, one would see that the space is still there.


Reproducible: Always

Steps to Reproduce:
1. compose a message like below:
---
 one space before
1234
----

2. Send to oneself; open the message.
   Composed and view, all in plain text.

Actual Results:  
When one opens the message, one would see:

a. in main message window

---
one space before
1234
---

Expected Results:  
b. if view in "view message source", one sees:

---
 one space before
1234
---


1. It may have some relation to:
   "spaces not always trimmed before user-inserted hard line breaks"
   https://bugzilla.mozilla.org/show_bug.cgi?id=227638
   which also happens in mine as well.

2. I believe it also exists in:
   thunderbird-1.0.2-sparc-sun-solaris-2.8 distribution

3. I'm runing on: % uname -a 
   SunOS (hostname) 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-1000

Comment 1

[Chris Chen]

I read "https://bugzilla.mozilla.org/show_bug.cgi?id=227638"
more carefully, and tried out:

>user_pref("mailnews.send_plaintext_flowed", false);
>user_pref("mailnews.display.disable_format_flowed_support", true);

It fixed the problem.  My mail doesn't go out with
"format=flowed" any more.  I guess I'll leave it up to you
guys to decide whether this is or isn't a bug.

Comment 2

[Mike Cowperthwaite]

I'm guessing that the message was composed as HTML, but sent as plain text.  If you'd composed as plain text, the line would have been sent out (with f=f) with two spaces at the beginning, and the first would have been (correctly) removed before display.  If my guess is correct, this is essentially a dupe of 
bug 125928.

Comment 3

[Chris Chen]

Reply to comment #3:

I did and spec everything, that I know of, in text, if this helps.

Thx.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> Reply to comment #3:
> 
> I did and spec everything, that I know of, in text, if this helps.

I just remembered, there is a related problem when composing in plain text: if you have the wrap column set to 0, the same problem of failure-to-format-as-f=f occurs -- that's bug 261467.

(Just to be sure on the composing-as-plain issue: a plain-text compose window does not have an Insert or Format option in the top-level menu.)

Comment 5

[Chris Chen]

Yes, I have my wrap col=0 for plain text.  I didn't know
how else to tell it not to wrap, other than a big number.

In any case, there seems to be bunch of related bugs filed.
I don't how the bugzilla folks prune the list;  I'll leave
it to the decision makers.  Thx for all the comments.  I'll
continue to answer questions if needed.

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> Yes, I have my wrap col=0 for plain text.  I didn't know
> how else to tell it not to wrap, other than a big number.

Well, one of the reasons f=f was developed was to not require the actual sent text to be sent out as one-long-line-per-paragraph while still allowing the receiving client to display the message with dynamic reflow.  Some people still wish to insist that their message should be sent out as they envision it, but the fact is SMTP has a line-length limit (on the order of 1000 chars, I don't know the exact number) which can result in truncation of the line; to avoid that, Mozilla imposes a limit of its own (about 990 chars).  If you create a paragraph longer than 990 characters, not only will it be wrapped but the wrap point can occur mid-word.

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