User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: version 2.0.0.5 (20070716) If I compose an e-mail that's mostly plain text, but with one or more paragraphs set to Preformat, I'd expect to get the HTML Mail Question dialog box when I send. Instead, if preformat paragraphs are the only formatting in an otherwise plain-text e-mail, it goes out as plain text. I sometimes use Preformat on snippets of command-line transcript where I want to control long lines and wrapping precisely. Without the option to send as HTML, a jumbled mess gets sent. Reproducible: Always Steps to Reproduce: 1. Options set: Composition / General / Send Options... / Text Format set to "Ask me what to do" 2. File / New / Message 3. Fill in recipient, subject 4. In body, type some text 5. For one body paragraph, do Format / Paragraph / Preformat 6. Hit send button Actual Results: Message sent immediately Expected Results: Should get HTML Mail Question offering the option of sending as plain text or HTML. If I set one paragraph to another format, like "Heading 1" I do get the HTML Mail Question dialog box when I send. I know of no workaround, other than making some relatively innocent HTML formatting, like bolding a period.

Reporter what is your "send option"? 1. ask me what to do 2. convert the message in plain text 3. send message in HTML anyway 4. send then message in both plain text and HTML Could you try to see if it still happens with http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ ?

Send option is set to "ask me what to do". I'll check out that pre-release and give you feedback. It'll be on a mac since I can't load pre-release stuff on my Windows (work) system.

WFM here on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090923 Lightning/1.0pre Shredder/3.0pre ID:20090923031438

Doesn't work for me. Exact same symptoms as before. I've set the send options to "ask me what to do". Still trouble if preformat is the only HTML formatting. I get the prompt for other formatting (e.g., bold) or if I use my typical workaround (format the preformatted block to color black). But if preformat is the only formatting, it goes out as plain text without prompting. This is on a mac. Version from "About Shredder" is Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090923 Shredder/3.0pre

WFM on Windows but don't work on Mac OS X: changed plataform field.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090923 Shredder/3.0pre : confirming.

Tested on Thunderbird 3.1RC1, Mac OS 10.6.3. Still there, exact same symptoms. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100526 Thunderbird/3.1

Confirmed this still exists on Windows. Not Mac-specific. Exact same symptoms. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100526 Thunderbird/3.1

(In reply to comment #8) > Confirmed this still exists on Windows. Not Mac-specific. Exact same > symptoms. > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100526 > Thunderbird/3.1 Can You test this with Seamonkey builds? I am betting you will get same behavior. If so this is an Editor bug and Msr Glasman needs to be CC: if he is still the module owner.

Confirmed in Windows Seamonkey 2.1a1. Exact same symptom. In all these recent confirmations (this + two tb3.1rc1) the workaround still works. Add any other formatting in addition to the preformat paragraph (color or bold some characters) and you get the HTML e-mail question. Preformat alone won't prompt w/ the HTML e-mail question. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100511 SeaMonkey/2.1a1

Confirming as described in comment 0. John (reporter) is right, both about actual and expected behaviour: <pre> tags are removed by {Delivery Format: Auto-Detect} which wrongly considers them "inconsequential" formatting that can be dumped in favour of sending plaintext. This is the other half of bug 414299 (see discussion about this on that bug). Fwiw, this bug is yet another example that our users reject the aggressive downgrading-to-plaintext algorithms of {Delivery Format: Auto-Detect} and, according to ux-wysiwyg, ux-control, ux-consistency etc. rightly expect their HTML compositions to be sent as HTML (no matter how little HTML there might be), instead of arrogantly deciding over their heads which formatting TB deems consequential or not, and unpredictably dumping such tags and their contained styles when sending.

Others and I just discovered this issue too. All I did was centered a section/paragraph. I did not bold, color, etc. SeaMonkey v2.33.1 thought I was sending a plain text without asking. :(

(In reply to John Maline from comment #7) > Tested on Thunderbird 3.1RC1, Mac OS 10.6.3. Still there, exact same symptoms. (In reply to John Maline from comment #10) > Confirmed in Windows Seamonkey 2.1a1. Exact same symptom. Phenomenon is already well known after your bug open. This is exactly same case as (C-1) of table of "User Story" of Bug 1210244. (C-1) When mixed recipients, (Unknown, or two or more in "HTML domain, Text Domain, Unknown"), if HTML is considered "Convertible to text" by Tb, mail is silently sent as text/plain by Tb with unknown reason, without using Send Options setting. As for "<PRE> only" case, it's same as "no tag, Body Text only" in latest build and it's still same in both SeaMonkey and Thunderbird, because design/implementation is not done. However, in <P> only case, it may be different in SeaMonkey and Thunderbird. Please be careful about difference between SeaMonkey and Thunderbird. To bug opener, do you see your problem in latest SeaMonkey and latest Thunderbird? (I think answer is Yes). If you need workaround, please see Bug 1204379 Comment #12 for known workaroud. If you think "sent as text/plain shouldn't occur when P only case or PRE only case, please close your bug as dup of Bug 414299, and please add comment/request to that bug. If you think Tb's behavior in above (C-1) is not so well, please watch Bug 1210244. We are trying to use alreasy-availble "Send Options panel" in above (C-1) case.

Oh, "Depends on: Bug 414299" was done by Thomas D. It's perhaps reason why this bug was fortunately not closed as dup of that bug :-)

(Off-Topic) To Thomas D., when I go to a bug, you already stay in the bug, and when you go to a bug, Wayne stays in the bug :-)

(In reply to WADA from comment #13) > To bug opener, do you see your problem in latest SeaMonkey and latest > Thunderbird? > (I think answer is Yes). Confirmed yes for Thunderbird 38.3.0 on Windows. Not going to go install SeaMonkey for an almost certain confirmation there too. > If you need workaround, please see Bug 1204379 Comment #12 for known > workaround. Don't all those workarounds boil down to "always send HTML" or "always force the HTML Mail Question"? If so, neither is a great workaround. I prefer sending plain text for a truly plain text message. And asking every single time (even should-be-clear cases) is a recipe to do the wrong thing half the time. If I missed a good workaround, could you be more specific? > If you think "sent as text/plain shouldn't occur when P only case or PRE > only case, please close your bug as dup of Bug 414299, and please add > comment/request to that bug. > If you think Tb's behavior in above (C-1) is not so well, please watch Bug > 1210244. I don't see the distinction between the two cases. Seems like they're saying the same thing regarding the current Thunderbird behavior. > We are trying to use already-available "Send Options panel" in above (C-1) > case.

(In reply to John Maline from comment #16) > I don't see the distinction between the two cases. Seems like they're saying > the same thing regarding the current Thunderbird behavior. You are right. Start point is same phenomenon. However, relevant tag depends on bug report, and requested solution in bug is different. > I prefer sending plain text for a truly plain text message. What is your definition of "truly plain text message". No tag except <html>, <head> <body> in HTML created by your operation using Composer of Thunderbird? If so, your case is not dup of Bug 414299, because externally same phenomenon but relevant tag is diffrent. <P>, <PRE> is in same group as "Body Text". This is current design, and it'll be not changed. If you want to create "truly plain text message" with setting default compose mode of identity=HTML? why you don't use Shift+Compose, Shift+Reply, Shift+Forward? > And asking every single time (even should-be-clear cases) is a recipe to do the wrong thing half the time. Does it mean following? If all recipients can receive HTML, and if Not HTML of "truly plain text message", silently sent as text/html. If Text Domain recipient is contained, and if Not HTML of "truly plain text message", Always Asked. If all recipients can receive Text mail, and if HTML of "truly plain text message", silently sent as text/plain. What is your expectation on Prefers=Unknown type recipient? Currently it's following. - If all recipients are HTML Domain type, silently send as text/html. - If all recipients are Text Domain type, silently send as text/plain. - If Unknown type recipient is involved or both HTML Domain and Text Domain is involved, - If HTML is "almost plain text message for Thunderbird(not for user)", even when Ask is requested at Send Options panel, silently send as text/plain without using Send Options. Cause of many bugs relevant to Auto-Detect is this behavior of Thunderbird. Treatment of Unknown type recipient is not good. - Else use Send options settong, and if Ask is set, Ask to user. Problem is : "almost plain text message for Thunderbird" !== "truly text message for user". And, "truly" depends on user. And, expectation on Prefers=Unknown depends on user.

Question on <P> and <PRE>. As for line break processing, IUUC, there is no difference between text/html part of multipart/alternative and text/plain part of multipart/alternative. When sent as text/plain only, this "text/plain part of multipart/alternative" is sent. Difference is following only. If text/html, by mailer, variable width font is used for P, and fixed width font is used for PRE. If text/plain, same font is used for text from P nd text from PRE. Is this so big difference in comunicaation betwee peoples using text in Email? Your claim is "if both P and PRE is used, should be sent as text/html"?

Question to avoid my misunderstanding. To bug opener. Is "P and Body Text only with no formatting" "truly plain text message" for you? Or not? Is "PRE and Body Text only with no formatting" "truly plain text message" for you? Or not?

(In reply to WADA from comment #19) > Question to avoid my misunderstanding. > > To bug opener. > Is "P and Body Text only with no formatting" "truly plain text message" for > you? Or not? No strong opinion. Never do this really. I'd lean "yes". > Is "PRE and Body Text only with no formatting" "truly plain text message" > for you? Or not? No. As described in opening the bug, I use PRE specifically when sending message where I'm trying to control line wrap (e.g., code snippet, log output snippet, etc). PRE is formatting in my opinion. Seems pretty clear because the resulting message has significant formatting difference when I do manage to successfully send as HTML.

(In reply to WADA from comment #18) > Question on <P> and <PRE>. > As for line break processing, IUUC, there is no difference between text/html > part of multipart/alternative and text/plain part of multipart/alternative. > When sent as text/plain only, this "text/plain part of > multipart/alternative" is sent. > Difference is following only. > If text/html, by mailer, variable width font is used for P, and fixed > width font is used for PRE. > If text/plain, same font is used for text from P nd text from PRE. > Is this so big difference in comunicaation betwee peoples using text in > Email? In general HTML the line break stuff is certainly part of the definition of PRE. Is there some specialized HTML via email spec I'm not familiar with?? http://www.w3.org/TR/2014/REC-html5-20141028/grouping-content.html#the-pre-element > Your claim is "if both P and PRE is used, should be sent as text/html"? I never mentioned P. Only PRE. Not sure how P got into the conversation.

(In reply to John Maline from comment #20) > > Is "PRE and Body Text only with no formatting" "truly plain text message" for you? Or not? > No. As described in opening the bug, I use PRE specifically when sending > message where I'm trying to control line wrap (e.g., code snippet, log > output snippet, etc). PRE is formatting in my opinion. Seems pretty clear > because the resulting message has significant formatting difference when I > do manage to successfully send as HTML. As for PRE, there is no difference in line break from Body Text in HTML to Text conversion, except when pretty long line length, If Body Text, may be wrapped by Tb while composing(<BR> may be inserted by Tb even when you don't press Enter). Body Text/P : Line Break=<BR> in HTML => in text/plain by Tb : 0x0D0A=CRLF. PRE : Line Break=0x0D0A=CRLF in HTML => in text/plain by Tb : 0x0D0A=CRLF. Line break is not lost when sent as text/plain. Biggest difference is: (due to HTML spec). Body Text/P : Shown with Variable Width Font by mailer of recipient, as done on P. PRE : Shown with Fixed Width Font by mailer of recipient. Plain Text : Shown as Font which is set in recipient's mailer. So, all text from Body, P, PRE is shown with same font. There is no gurantee that recipient uses Fixed Width Font in text mail display. "Date when sent as text/plain" is "Data in text/plain part of multipart/alternative"(Delivery Format=Both). By "Send Both", You can see line break is not lost by HTML to Text conversion of Body Text/<P> and <PRE>. See Attachment #8671129 [details] (attached to bug 1210244) for current "almost truly plain text message for Tb", please. FYI. (1) Official method to force text/plain : Compose in Text mode(Shift+Compose/Reply/Forward), or Delivery Format=Plain Text Only aat menu. (2) A known simple method to force sending as text/html : background color = #FEFEFE. msgcompose.background_color = #FEFEFE (any value except #FFFFFF) This can be called hidden official option of "Kill Auto-Downgrade by Auto-Detect" :-) Who can recognize difference between #FFFFFF and #FEFEFE? Your request involves "if PRE is used, ask or send as text/html", "if Body and P only, silently send as text/plain", so there is no way to fulfill with composing mail in HTML mode. I think enhancement for such request will not be done. It may better to consider use of <code>, <smap> etc. instead of <pre>. Anyway, thanks for answers. I could udnderstand request of this bug.

FYI. To use <code>. <samp> etc., use of Insert HTML is needed. Text Editor, Composer of Tb etc. can be utilized to creating inserting HTML.

(In reply to WADA from comment #22) > As for PRE, there is no difference in line break from Body Text in HTML to > Text conversion, except when pretty long line length, Long lines. That's exactly the interesting case.

(In reply to WADA from comment #23) > To use <code>. <samp> etc., use of Insert HTML is needed. Text Editor, > Composer of Tb etc. can be utilized to creating inserting HTML. The paragraph format UI has PRE as an option. If your workaround is to go into Insert / Insert HTML... then that's a far worse workaround than the traditional "bold one period" workaround. Assuming I remember to use one of the workarounds (before accidentally sending an jumbled message).

Uploaded an example of how the e-mail arrives if the PRE formatting is lost.

Here's the equivalent case where the PRE worked due to remembering to use a workaround that allows me to specify HTML format.

John Maline, please check both text/html part and text/plain part in multipart/alternative. Even if long line in PRE, because this is Email, "restriction of max line length in mail data <= 1000 bytes" is applied. To avoid this length limt in mail data, "send in base64" like action is needed, and Gmail looks to do so. See Bug 653342 for such issue. In that bug, phenomenon of this bug is relevant, because, if this bug occurs at sae time, text/plain only is sent and text/html part is not sent. So, this bug make worse phenomenon of that bug.

If sent as text/plain only after HTML to Text conversion by Tb, format=flowed is applied. So, if long line in PRE, displayed layout is perhaps different from user's expectation. This is a "format loss" for user in PRE case.

By the way, if following HTML(create by Insert HTML), loss of "blue box around <p>" is known at a glance. <body><p style="border: solid 3px #0000FF;">Text in paragaraph</p</body> See dependecy tree for meta bug 889315(search CSS or Style), please. I recommend you "Shift+Compose" + "hidden official option of 'Kill Auto-Downgrade by Auto-Detect'" :-) See Bug 1204379, and see Bug 1210244 for current status around "silently sent as text/plain by Auto-Detect", please.

Good things come to those who wait... (Was lange währt, wird endlich gut) I finally fixed this in bug 1385636. So explicit "Preformat/<pre>" formatting in your HTML messages will now be preserved when sending and actually do what it says :) Sorry for the inconvenience caused until now, but in a classic case of ux-implementation-level, fixing this bug had hitherto been aggressively blocked for all the wrong reasons. Btw, please note that auto-downgrading of HTML messages to plaintext is optional since my implementation of bug 136502: There's a checkbox in Tools > Options > Composition > General > Send Options: [ ] Send message as plaintext if possible