285187 - Forwarding HTML e-mail from Sent folder changes e-mail to text only

Status: RESOLVED DUPLICATE of bug 249093

(Thunderbird :: Message Compose Window, defect)

Description

[Nick Howitt]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-GB; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: version 1.0 trunk (20050307) also official 1.0

If I try to forward any HTML e-mail I have sent (i.e. from the sent folder)
which contains long lines, it gets converted to text only with a fixed line length.
Forwarding from the InBox is OK.

Reproducible: Always

Steps to Reproduce:
1.Choose any e-mail in the sent folder, which only contains a message you have
composed (i.e. not a reply), written in HTML format containing long lines
2.Click Forward
3.

Actual Results:  
A compose window is opened, but the original message is now in test only format
with a fixed line length.

Expected Results:  
It should have left the original message in HTML format as it does when I
forward a received message

It also happens to some, but not all messages which in the sent folder which are
replies. I cannot identify the pattern for these messages.

Comment 1

[Mike Cowperthwaite]

(In reply to comment #0)
> If I try to forward any HTML e-mail I have sent (i.e. from the sent folder)
> which contains long lines

Does this mean you have composed those lines with Preformat (<pre>)?

> it gets converted to text only with a fixed line length.

Not sure what you mean by this.  Is the message compose window using the plain 
text editor or the HTML editor?  (If you're not sure, see if the Options menu 
has a Format submenu.)

See bug 254928, bug 237558 and bug 262476.  I suspect this bug is a dupe of the 
first of those.  If you don't think that this is the case, please save a sample 
message from your Sent folder as a .EML file and attach it to this bug, using 
the Create New Attachment link above.

Comment 2

[Nick Howitt]

Attachment: Message 1 in eml format

Comment 3

[Nick Howitt]

Attachment: Message 1 in the correct html format

Comment 4

[Nick Howitt]

Attachment: Message 2 in correct eml format

Comment 5

[Nick Howitt]

Attachment: Message 2 in correct html format

Comment 6

[Nick Howitt]

Mike,
Looking at the other bugs, I do not think it is 254928. The other ones appear to
match more closely. Unfortunately things like <pre> tags and re-flow mean
nothing to me.
The bug also appears when saving eml messages as you will see from the attachments
I have saved 2 messages twice, once as eml and once as html.
Attach1.html is how the message should look. The message was sent in the default
TB html format. Attach1.eml is how it saves as as an eml file where the lines
appear to be fixed at about 73 characters long. In the correct version, the
messge is just one long line and should only wrap at the edge ot the window.
Attach2.html and .eml both look OK when forwarded or saved.

When forwarding, the compose window has an Options/Format sub-menu.

Other things to note are that this account is defaults to composing messages in
HTML format and to forwarding messages inline. Also when replying to Attach1,
the formatting is correct.

It also looks like I have not worked out how to correctly attach my files to the
bug reports! Sorry for the multiple posts.
Nick

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> Attach1.eml is how it saves as as an eml file where the lines appear to be
> fixed at about 73 characters long.

OK, now I see. This message was sent as plain text, even tho you composed it as 
HTML.  This conversion happens without notice when you compose an HTML message 
but (1) don't use any formatting (bold, color, font size, etc), and (2) one or 
more recipients of the message are either unlisted your address book or listed 
as "prefers plain text" or "unknown."  This behavior is unlikely to change; an 
earlier bug about this was WontFix'd.

When you forward such a message, since it's "plain text", it "formats" the text 
within the HTML message as "Preformat".  As I noted at bug 237558, this is 
actually desirable if the original message was not format=flowed, since there 
are (well, there may be) legitimate reasons to keep those lines from reflowing; 
but if the original is format=flowed -- as your sample message is -- then the 
text should not be Preformatted but simply copied, in the same way a reply is.  
This symptom is bug 249093.



> It also looks like I have not worked out how to correctly attach my files to
> the bug reports! Sorry for the multiple posts.

Doesn't look like you did anything wrong there -- you have to enter a new 
comment for every attachment.

(In reply to comment #0)
> It also happens to some, but not all messages which in the sent folder which
> are replies. I cannot identify the pattern for these messages.

As stated above, this will happen if the message was sent as plain text without 
format=flowed.  Mozilla turns on f=f by default, as do some other clients, but 
not (I believe) Outlook Express (that may not support sending f=f messages at 
all).  If you are seeing this problem with replies for text/plain, f=f messages, 
that would be a different bug.

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

Comment 8

[Nick Howitt]

Thanks for the relpy.

I would find it very hard to accept any argument which allows replies and
forwarded messages to be treated differently. At the moment, if I reply to the
first massage, it works as I would like it i.e. it preserves formatting. I do
not see why forwarding should not do the same. I agree the bug possibly sounds
like #249093. 

Should I raise another bug that saving an eml file also does not preserve
formatting for my simple e-mail attach1 but does for attach2?

Comment 9

[Mike Cowperthwaite]

(In reply to comment #8)
> I would find it very hard to accept any argument which allows replies and
> forwarded messages to be treated differently. 

I agree; that's why the dupe is a bug.


> Should I raise another bug that saving an eml file also does not preserve
> formatting for my simple e-mail attach1 but does for attach2?

The short answer: No, because there is no bug there.

The sent message *is* a plain text message; saving it as a .EML shows exactly 
what was sent to your recipient.  The actual lines of text sent across should 
not be sent as a long single line per paragraph, which you seem to believe is 
the case; the standard for sending mail recommends always breaking text lines at 
80 characters or less, and SMTP fails for lines longer than some large limit 
(like > 1000 characters).

HTML mail, and format=flowed plain mail, attempts to achieve the sort of display 
you expect, by reflowing the text as well as wrapping it to the window edge.

You may not like the fact that Mozilla converts your HTML message into plain on 
sending, but there are sound arguments for that as well; see bug 273561.