22.07 KB, application/pdf
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 I set up a very important document with correct business format and send it on its way. I look in the sent box and to my dismay the email is formatted completely wrong and Thunderbird has taken out all the spacing and totally botched my email. I understand that this could be because of window sizing but it's ridiculous. I hit enter to create a blank line in the email and once it sends Thunderbird manages to delete the line. Reproducible: Always Steps to Reproduce: 1.Create a letter with a lot of formatting( different paragraphs,spacing, and indenting) 2.Send the letter 3.Look and see how Thunderbird manages to destroy all formatting done to the letter. Actual Results: An email with formatting completely seperate of that which you had anticipated. Expected Results: Emailed the letter just as it was formatted. Window Size most likely plays a role in the problem.
are you using the html compose window?
(In reply to comment #1) > are you using the html compose window? > I'm using the compose window that you click on when Thunderbird opens.
and does it have formatting buttons on the toolbar (html compose) or not? Which compose window that comes up depends on which options you've chosen, and how you open the window. Was the message that got sent in html or not? You can tell by looking at the message source of the msg in the sent folder.
Yeah, it has formatting things on the toolbar. It was in plain text. Is that my problem? That will make me mad if it is...
It never asked for plaint text or html text. I never got prompted.
(In reply to comment #5) > It never asked for plaint text or html text. I never got prompted. First, check the settings at: Tools | Options | Composition | Send Options Check both the dropdown and the "Plain Text Domains" tab. Next: is the person you're mailing to in your address book? If so, check this setting at their address card: "Prefers to receive messages formatted as ..." The way TB handles an HTML-composed message is: - if *all* recipients "prefer HTML" or are in an HTML domain, message is sent as HTML; - if *all* recipients "prefer plain" or are in a plain-text domain, message is sent as plain; - if message contains no formatting [*], message is sent as plain (see bug 157346); - if message contains any formatting, processes the message according to the Send Options (see bug 187064). [*] One bug with the check for "has formatting" is that an <img> is not considered formatting, and (worse) will be dropped if the message contains no other formatting -- bug 180997.
(In reply to comment #6) I completely agree with the submitter that the behavior is extremely frustrating. My messages have been silently un-formatted many times and I could never figure out why (until I happened on Mike's explanation above). In my case my preference is to be asked. I sometimes send a formatted message to several recipients from my address book. One of them is "prefers text" and all the others are "unknown." Since unknown isn't considered a conflict with prefers-text or prefers-HTML, it never asked me what to do, leaving me irritated that all my careful formatting effort had been silently thrown away. I think the user would be better served if "unknown" would force a conflict with "prefers text" and cause the decision to be made based on the Send Options preference.
(In reply to comment #7) > In my case my preference is to be asked. I sometimes send a formatted > message to several recipients from my address book. One of them is > "prefers text" and all the others are "unknown." Since unknown isn't > considered a conflict with prefers-text or prefers-HTML It *used* to be that the silent conversion to plain happened if *any* recipient preferred plain, but your observation is no longer correct -- I checked that before posting comment 6 and I just double-checked. If one "prefers plain" and another's pref is unknown, it falls back to the "Send Option" setting -- asking what to do, or sending as plain+HTML, etc. The behavior changed before TB 1.0 was released, with the patch for bug 243133. Mozilla traditionally has been aggressive about downconverting to plain text because there are valid reasons for discouraging HTML (and some not-so-valid reasons as well, which are nonetheless championed by insistent and loud old-school hackers).
(In reply to comment #8) > It *used* to be that the silent conversion to plain happened if *any* > recipient preferred plain, but your observation is no longer correct You're right; sorry for that misstatement. Turns out my Bcc address was "prefers text," not "unknown" like I thought. > Mozilla traditionally has been aggressive about downconverting to plain text > because there are valid reasons for discouraging HTML (and some not-so-valid > reasons as well, which are nonetheless championed by insistent and loud > old-school hackers). I'm pretty old-school myself, but I value being able to send formatted mail when I need to. I don't mind that TB silently downconverts when no formatting has been used, but I think the user ought to be warned (if he chooses) when formatting information is going to be discarded, even if all recipients "prefer" text. (The user might not interpret "Prefers Text" as "Requires Text.")
Confirming this. Some types of formatting are not recognized as requiring HTML when the (default) formatting option is Auto-Detect. Center alignment is silently lost, as is white space such as tabs. It's extremely frustrating to spend time formatting an e-mail only to have those changes silently dropped and have your e-mail sent looking like a piece of garbage.
Created attachment 244673 [details] this is a PDF of an e-mail from my father who has documented the source of the bug gratuitous changes in formatting (loss of carriage return) the problem occurs in sending of e-mail where the sent file has necessary carriage returns deleted by the composer. The displayed file is what the user wishes to send but the sent file has blank lines between paragraphs stripped during send. The root problem has been found and is how Mozilla and Thunderbird treat a blank space before a carriage return at the end of a line. Only the blank space is returned. See the attachment for an example of this effect.
Comment on attachment 244673 [details] this is a PDF of an e-mail from my father who has documented the source of the bug further to above data, this problem is for mail sent in PLAIN TEXT mode - no idea if any of this applies to HTML coded mail as I refuse to use that
The behavior described in comment 11 isin fact not a bug, but the intended behavior. Please refer to bug 168420 and the mini-FAQ attached to that bug; information on disabling f=f is found there, if desired.
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 18.104.22.168)
Whiteboard: closeme 2008-09-04
RESO INCO due to lack of response to last comment. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.