User Agent: Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141027150301 Steps to reproduce: (1) In Windows Explorer, right-click a proposed attachment and SEND-TO email recipient. (2) Switch to the resulting TB compose window and type some text. Add bolding, colour, whatever. CASE 1: (3.1) Save to DRAFT for later. (4.1) Re-open the letter to continue. CASE 2: (3.2) Send the letter to someone (such as yourself). (4.2) Open the email for viewing. Actual results: Running TB 31.2.0 under Windows 7/32... When creating the body of the email, the editor behaves normally and formatted text appears as usual. But after the email has lwft the composer (Case 1 - saved and re-opened, or Case 2 - sent out), all HTML formatting is lost and the body defaults to simple text. And of course, once lost, formatting cannot be restored. (Nor can the composer be persuaded to use HTML editing -- which is another issue. :) Expected results: HTML formatting should be maintained throughout the process. Using the exact same conditions as above, if I use WRITE to create the new email, then add the attachment via the menu, then save or send, the message maintains its format correctly.

(In reply to Dan Pernokis from comment #0) > Actual results: > When creating the body of the email, the editor behaves normally and formatted text appears as usual. Does it mean that mail composition window was opened in "HTML mode" as expected? (opened with From: = 1-st identity of default account, and with composition mode of the identity) > But after the email has lwft the composer (Case 1 - saved and re-opened, or Case 2 - sent out), > all HTML formatting is lost and the body defaults to simple text. For Case 1 - saved and re-opened Is your observation and report correct? If mail is composed in HTML mode, draft is saved in text/html. (check it via. View/Message Source by yourself, please) When this draft mail is viewed, displayed result depends on View/Message Body As. If View/Message Body As/Plain Text, text/html mail is shown as "Plain Text", as done on ordinal received/sent mails. When this draft mail(text/html) is edited, it's edited in "HTML mode", with From: = identity specified in X-Identity-Key: header. At which step was "HTML mode" actually lost in your case? For Case 2 - sent out Tb has feature called "Auto-Detect of send format" which automatically downgrades to text/plain when HTML is not needed. For example, text only mail composed as HTML mail. This is sent in text/plain by Tb. This is perhaps a feature to avoid Text vs. HTML war, which might have happened when HTML mode was defaulted in Tb. So, phenomenon of "mail composed in HTML mode is sent as text/plain mail" can occur. In this case, "send in HTML" or "send both HTML and Text" should currently be explicitly requested by Tb user. This is known issue. See Bug 414299 etc. which are relevant to "Auto-Detect of send format". Are you talking about this issue? (You can check it merely by "Send Later" and View/Message Source) Some known simplest/easiest work round described in that bug, are as follows. - <B>&nbsp;</B> in your HTML signature - Text color in HTML mail composition !== #000000", for example, #000001 - Background color in HTML mail composition !== #FFFFFF, for example, #FFFFFE For "Auto-Detect of send format" of Tb, these are fortunately pretty important attributes which must not be lost by sending as text/plain. .

@wada - Comment#1... First, when I said that "the editor behaves normally", I mean it looks/feels/works as it usually does, which is to say the window is white (not yellow), the text is specific (not generic), and -- most importantly -- I added BOLD, ITALICS, and COLOUR to the text and the words changed appearance as commanded, which cannot happen in plain-text mode.. So as far as I can tell, yes, the editor is in HTML mode. Then, if I SAVE the email (or SEND LATER as you suggested), when opened, the email is now in plain-text mode -- the bolded text is enclosed between asterisks and the colour is gone. This is despite having started as HTML. However, you rightly state that view-source may show both formats, and sure enough both plain and HTML are present. As for sending, I didn't actually test it until tonight by sending to myself. I had just recently sent a message to our laptop and received a reply in plain-text -- that never happens, and I didn't know why. Then when I tripped over the problem with SAVE, I presumed it was the same cause because that's a reasonable explanation. (The laptop is running the same TB, with the exact same configuration as far as I can tell.) For the record, I do have the sending option set for BOTH (HTML and plain-text).

My Comment #2 continued... Forgot to say at the end: When sending, when I tested tonight by sending to myself, the message did come back with HTML formatting intact, when previewed and when opened in the editor for REPLY. So I can't say with confidence that it works or doesn't.

There is no need to send mail actually to some one. Following is sufficient for test. Compose HTML mail, regardless of New mail, Reply, Forward, do "Send Later", .then go to Outbox of "Local Folders" and View/Message Source, save as .eml file if needed, finally delete the generated mail in Outbox of "Local Folders". Because you added BOLD etc. while composing HTML mail, and because you say that "generated message source by Tb" was "both HTML and Text"(both text/plain part and text/html part is sent), "mail composed in HTML mode" is sent by Tb as HTML mail, as expected. "Format of reply mail" is all up to person who composed the reply mail and mailer which is used by him. Person who composed the reply mail and used mailer can create any of text/plain mail, text/html mail, multipart/alternative mail with both text/plain and text/html. In Tb, "Reply to text/plain mail" is composed in Text mode. If "Reply to text/html mail" or "Reply to multipart/alternative with text/plain and text/html", IIUC, composition mode is always determined by "mail composition mode" which is set in Account Settings/Composition&Addressing. And, Shift+Write(compose new mail), Shift+Reply, Shift+Forward, etc. are available to Toggle defaulted mail composition mode. Is replied by Tb? Or replied by other mailer? If replied by Tb, which composition mode is set in Account Settings/Composition&Addressing?

(In addition to comment #4) If SEND-TO, used identity is always "default identity(first identity of an account) of default account". This is different from ordinal mail composition in Tb. Check your Account/Settings/Composition&Addressing setting of all identities, please.

Reply to WADA Comment #5: >> If SEND-TO, used identity is always "default identity(first identity of an account) >> of default account". Didn't know this for sure but it makes sense and I suspected as much -- I see the dummy default account come up. In any case, ALL of my accounts are set to "compose in HTML", both on my main computer and on the laptop. They were intentionally set up that way, the two machines were also intentionally matched in this regard, and I verified the compose tab on all accounts on both machines (plus in detail on a few key accounts on both machines). ALL are still set to compose HTML, and the global settings on both machines are set to send in both formats (plain text and HTML). Reply to WADA Comment #4: >> Is replied by Tb? Or replied by other mailer? >> If replied by Tb, which composition mode is set in Account Settings/Composition&Addressing? The conversation was from my main machine to the laptop and back -- TB to TB to TB. And as I just said, both machines are set up identically to do everything in HTML. Most of our exchanges are simple -- no attachments -- written in text, sometimes formatted, but always composed, sent, viewed, everything, in HTML. The exceptional exchange (that confirmed my theory about SEND TO messing up) is very clear: I had cut a photo in PS, then in Windows (7/32) Explorer I did a SEND TO (which allowed me to compose in HTML), then I simply sent the message as usual. The replied message was in plain text. No other reply had ever been that way. (FYI, TB menu VIEW, MESSAGE BODY was set to view in HTML too.) And finally, the message still exists on the laptop and in my SENT box -- as plain text only! So obviously it was sent that way from here. Now I just said: >> The exceptional exchange (that confirmed my theory about SEND TO messing up)... I was livid after wasting half an hour on some tedious compositions. I was being lazy in doing a bulk emailing of business documents (several common docs and one recipient-specific for each). It was easy to click/select the common documents in Explorer and SEND-TO them to email recipient, edit the message (including HTML formatting such as colour and bolding) in the first resulting window, SAVE to draft, then clone the saved message several times, open them, and finally add the recipient-specific attachment and specific wording to each message. All done, all appeared to work, all windows were HTML display with bolding, etc. I saved often, as changes were made. Finally, I closed off everything (don't recall why, probably to do something else for a moment). Then -- horrors -- when I went back and opened the files from draft, all of the HTML formatting was gone -- permanently! All that time and tedium. Not a happy camper. So that brought up: What did I do? I used SEND-TO. And, oh, I did that on the photo email exchange with the laptop that mysteriously lost its HTML too. So I tested -- repeatedly, now -- and it fails. If I initiate create with WRITE, the message works (composes & stays HTML). If I initiate create with SEND-TO, the message fails (composes in HTML but loses its HTML formatting).

(In reply to Dan Pernokis from comment #6) > and the global settings on both machines are set to send in both formats (plain text and HTML). AFAIK, there is no such setting in Tb. - There is no way to change default of Delivery Format. Delivery Format/Auto-Detect is always used, unless user intentionally changes Delivery Format upon each Send. - In address book : Prefers Text, Prefers HTML, Unknown, only is selectable. - "Send Options/Text Format/HTML and Text(or HTML)" is applied to "When sending in HTML" only, as written in panel. If Tb thinks composed HTML is better sent as Text mail, IIRC, it's never "When sending in HTML". IIRC, "Send Options/Text Format" can do nothing in this case. And, <img> tag won't force "Send in HTML when Auto-Detect". Auto-Detect never stops "downgrading to Text" merely by "<img> tag is used". Because your composition format is set to "HTML" for all identities, mail compsition was always done in HTML mode. If Delivery Format=Auto-Detect, "mail composed as HTML" can be sent as text/plain mail by Tb. "Sent in plain/text in your case" is following, isn't it? When you use SEND-TO, composed HTML is usually simple, so Tb tries to downgrades to text/plain. BOLD is not used, text color is not used, signature is not used, ... Delivery Format/HTML and Plain Text(or HTML) is not always intentionally chosen by you. Mail recipients is not always set as "Prefers HTML" in your address book of Tb. > > Reply to WADA Comment #4: > >> Is replied by Tb? Or replied by other mailer? > >> If replied by Tb, which composition mode is set in Account Settings/Composition&Addressing? > The conversation was from my main machine to the laptop and back -- TB to TB > to TB. And as I just said, both machines are set up identically to do > everything in HTML. > > Most of our exchanges are simple -- no attachments -- written in text, > sometimes formatted, but always composed, sent, viewed, everything, in HTML. > The exceptional exchange (that confirmed my theory about SEND TO messing up) > is very clear: I had cut a photo in PS, then in Windows (7/32) Explorer I > did a SEND TO (which allowed me to compose in HTML), then I simply sent the > message as usual. The replied message was in plain text. No other reply > had ever been that way. (FYI, TB menu VIEW, MESSAGE BODY was set to view in > HTML too.) And finally, the message still exists on the laptop and in my > SENT box -- as plain text only! So obviously it was sent that way from here. > > Now I just said: > >> The exceptional exchange (that confirmed my theory about SEND TO messing up)... > I was livid after wasting half an hour on some tedious compositions. I was > being lazy in doing a bulk emailing of business documents (several common > docs and one recipient-specific for each). It was easy to click/select the > common documents in Explorer and SEND-TO them to email recipient, edit the > message (including HTML formatting such as colour and bolding) in the first > resulting window, SAVE to draft, then clone the saved message several times, > open them, and finally add the recipient-specific attachment and specific > wording to each message. All done, all appeared to work, all windows were > HTML display with bolding, etc. I saved often, as changes were made. > Finally, I closed off everything (don't recall why, probably to do something > else for a moment). Then -- horrors -- when I went back and opened the > files from draft, all of the HTML formatting was gone -- permanently! All > that time and tedium. Not a happy camper. > > So that brought up: What did I do? I used SEND-TO. And, oh, I did that on > the photo email exchange with the laptop that mysteriously lost its HTML > too. So I tested -- repeatedly, now -- and it fails. If I initiate create > with WRITE, the message works (composes & stays HTML). If I initiate create > with SEND-TO, the message fails (composes in HTML but loses its HTML > formatting).

Reply to WADA Comment #7... >> and the global settings on both machines are set to send in both formats (plain text and HTML). > AFAIK, there is no such setting in Tb. > - There is no way to change default of Delivery Format. Ahhh... I misread the global setting -- send both IF there is no indicator for the recipient's preference. None of my address book entries have the preference set -- and for sure our own addresses on main & laptop do not specify, so that way I could see the format flipping to plain text. But is that the correct thing to do? Sounds like you're saying this is a non-bug -- TB does what it does. So back to Comment Zero (and my rant about discovering the change in format)... (i) I would expect my composition to go through as I see it in the window if at all possible. (ii) I would expect consistency between using WRITE and SEND-TO to initiate creation -- they *MUST* be the same, because in both cases the sending-account-to-be and final destination(s) are not known until later. Therein lies the bug -- two different results from doing essentially the same thing. And this again: > AFAIK, there is no such setting in Tb. > - There is no way to change default of Delivery Format. ...then don't you think there should be? Agreed maybe there are instances when TB won't or can't send in HTML, but if at all possible it should if I tell/expect it to. Anyway, in the meantime I can work around the attachment issue (though it's not as convenient). But I think this issue should be looked at when time & resources permit.

(In reply to Dan Pernokis from comment #8) > But is that the correct thing to do? Sounds like you're saying this is a non-bug > -- TB does what it does. I don't know what is correct thing. And, current behavior is intended and is working as designed/implemented. Because of "working as intended/designed/implemented", this is not BUG in narrowest definition : BUG === flaw in code === not coded as designed && design is good, valid. correct, proper, ... However, needless to say, user's pretty normal and ordinal and proper and valid and .... expectation is usually perhaps "if he composed in HTML, sent in HTML". So, there is mismatch between user's expectation and Tb's behavior. Therefore, "bug reports in B.M.O" are already opened for it. See Dependency tree for meta Bug 889315. Because "magic" is kindly provided by developer, we can say "there is setting to skip automatic downgrade to Text", as I already stated in comment #1. If "automatic downgrade to Text" is skipped, "When sending in HTML" in Send Options/Text Format is applied by Thunderbird to all mails which was composed in HTML by user. "Skipping automatic downgrade to Text" is currently pretty simple and easy. Do it. Text color = #000001, or Background color = #FFFFFE Or if you use signature, <B>&nbsp;</B> in your HTML signature Which bug do you like as "bug to which this bug is duped to"? Bug 136502? Bug 414299? Bug 584363? Other? Are we better to open bug of "default Text color in HTML composition(msgcompose.text_color) should be #000001 in order to skip automatic downgrade to Text"? :-)

Discussion of *THIS* bug has covered a range of problems, workarounds, etc, all covered in various ways by Meta Bug 889315. I want to reset *THIS* bug to its original problem: With regard to HTML vs plain text formatting -- when a new message is created, there is an inconsistency in the subsequent process stream between [messages created by the WRITE Button + Attachments Added] VERSUS [messages initially created by the Windows Explorer SEND-TO operation]. I will link directly to Meta Bug 889315, since *THIS* bug at the same time IS and IS NOT a duplicate of the others listed there.

@WADA: Thanks for your help, comments, and useful advice on this!

Sorry, I didn't mean to close this bug -- I just meant to refer to Bug 889315.

Meta bug is for tracking of bugs for each actual problem, so "duping to meta bug" shoudn't happen in B.M.O :-)

(In reply to WADA from comment #9) > (In reply to Dan Pernokis from comment #8) > > But is that the correct thing to do? Sounds like you're saying this is a non-bug > > -- TB does what it does. > > I don't know what is correct thing. > And, current behavior is intended and is working as designed/implemented. > Because of "working as intended/designed/implemented", this is not BUG in > narrowest definition : > BUG === flaw in code === not coded as designed && design is good, valid. > correct, proper, ... > However, needless to say, user's pretty normal and ordinal and proper and > valid and .... expectation is usually perhaps "if he composed in HTML, sent > in HTML". So, there is mismatch between user's expectation and Tb's > behavior. Therefore, "bug reports in B.M.O" are already opened for it. See > Dependency tree for meta Bug 889315. > You can also try my "Always HTML" add-on (https://addons.mozilla.org/pl/thunderbird/addon/always-html/), designed to just turn off this annoying misfeature. With the "Always HTML" TB will no longer downgrade HTML mails to plain text.

(In reply to Dan Pernokis from comment #10 > when a new message is created, there is an inconsistency in the subsequent process stream > between [messages created by the WRITE Button + Attachments Added] > VERSUS [messages initially created by the Windows Explorer SEND-TO operation]. What is essential difference or inconsistency in the subsequent process stream between them? As far as composition window is invoked in HTML composition mode, I believe difference is following only: SEND-TO : (==Always new mail composition) Default identity of default account is used upon start of mail composition. New mail composition at Tb : Default identity of currently selected account is used upon start of mail composition. Note: If reply, composition mode is affected by format of Replied mail. I don't refer to such case. It's pretty consistent, isn't it? : Tb freely sends in Text, when Tb wants to send it in Text :-)

(In reply to Arivald from comment #15) > You can also try my "Always HTML" add-on > (https://addons.mozilla.org/pl/thunderbird/addon/always-html/), > designed to just turn off this annoying misfeature. Your addon replaces DetermineConvertibility() and returns nsIMsgCompConvertible.No if compsed in HTML. I believe it's correct action for us. But msgcompose.text_color=#000001 in mailnews.js like one is safer. It's merely a slight color change for user and it never touches Composer code nor Auto-Detect code nor auto-downgrade code, So no one can protest against default color change merely by that Auto-downdrade, which is loved very deeply in Tb, will be killed. If someone want to protest against slight color change, he must describe about "Why Tb must send mail in HTML when #000001 but Tb must send in Text when #000000" :-) Anyway, can you introduce your addon in meta Bug 889315?

(In reply to Dan Pernokis from comment #10 > when a new message is created, there is an inconsistency in the subsequent process stream > between [messages created by the WRITE Button + Attachments Added] > VERSUS [messages initially created by the Windows Explorer SEND-TO operation]. Are you talking about difference between following? Composition type Generated HTML by Tb (a) SEND-TO of image file : HTML with text only, Image file is ATTACHED (b) Write in Tb + Drag image to attcahment box : HTML with text only, Imaage file is ATTACHED (c) Write in Tb + Drag image to HTML body : HTML with text and EMBED IMAGE Because HTML source of (c) is different from (a)/(b), result can be different. But it can not be called "inconsistency", because it's different result in different conditions.

(In reply to WADA from comment #18) > (In reply to Dan Pernokis from comment #10 > > when a new message is created, there is an inconsistency in the subsequent process stream > > between [messages created by the WRITE Button + Attachments Added] > > VERSUS [messages initially created by the Windows Explorer SEND-TO operation]. Which is so reminiscent of, albeit not a duplicate of, Bug 378046 - Mail composition: opening/editing attached file sometimes unexpectedly opens/edits original file (only if attachment was added via TB OR drag-and-drop (non-MAPI) AND draft has never been closed yet): MAPI and non-MAPI behaviour should be consistent ...where MAPI is the Windows Send-To behaviour...

@Thomas D. - Reply to Comment #19... Ah-ha!! So it did used to happen! Someone told me that clicking an attachment also edits the original, and I said no, it used a temporary copy only. They must have tried it during the bug -- and they think to this day that it still works that way. :)

@WADA - Reply to Comment #16... > What is essential difference or inconsistency in the subsequent process stream between them? > As far as composition window is invoked in HTML composition mode, I believe difference is > following only: > SEND-TO : (==Always new mail composition) Default identity of default account is used upon > start of mail composition. > New mail composition at Tb : Default identity of currently selected account is used upon > start of mail composition. > Note: If reply, composition mode is affected by format of Replied mail. I don't refer to such case. I agree that SEND-TO has to use *something* and the default identity of default account makes sense (as I acknowledged previously). But I did specify a sender before saving to draft, so it knows the identity I will be using. Using WRITE (if this is "New mail composition at Tb" above), there is also no account specified or known until I specify it, but again I did specify the same sender before saving to draft. Are you saying (by "currently selected") that it uses whatever account was used last time??? (I am *not* using forward or reply which may newly edit a message, so there is no "currently selected" anything.) Go back to my rant at the bottom of Comment #6: When I created the email with SEND-TO, and when I created the email with WRITE & add attachment, they were step by step, condition by condition, intentionally IDENTICAL in both cases. And when they are then both saved to DRAFT, closed, and re-opened, then: (i) the WRITE version continues working in HTML, with correct colours and bolding as expected; while (ii) the SEND-TO version has irrevocably switched to plain text, permanently losing its HTML formatting. I don't understand how changing colour from #000000 to #000001 would stop the switch to plain text, but red would not. And I thought bolding & italics are HTML controls. Bolding & italics become "*bold-text*" and "_italics-text_" in plain text but do not convert back if trying to do HTML -- and all colours are gone. This isn't as simple as deciding to go plain-text -- there are colours and bolding present that must not be ignored. And it isn't just adding an attachment in the WRITE version. I manually added one additional attachment in both cases, so that is common too.

@WADA - Reply to Comment #18... > Are you talking about difference between following? > Composition type Generated HTML by Tb > (a) SEND-TO of image file : HTML with text only, Image file is ATTACHED > (b) Write in Tb + Drag image to attachment box : HTML with text only, Image file is ATTACHED > (c) Write in Tb + Drag image to HTML body : HTML with text and EMBED IMAGE > > Because HTML source of (c) is different from (a)/(b), result can be different. > But it can not be called "inconsistency", because it's different result in different conditions. Just for the record, the attachments were PDF files, not images -- but they're handled the same, aren't they? Common to Cases (a) and (b): I re-created the problem following the steps used in real life -- first series of emails (with SEND-TO) failed unexpectedly, subsequent series (using WRITE) worked successfully and as expected. In real life, I copied (cloned) the draft email, using it as a template to create multiple copies to which I could add specific attachment, subject line, and other recipient-specific info. (In the re-creation, the cloning is irrelevant -- the problem shows up when the items are closed after saving, which happened only when I was finished.) Not sure what you mean by "text only" -- there was text, but I coloured and bolded it. Context: "manually attached" means I used the ATTACH button on the composer menu bar. (Does this operation vary from dragging?) Case (a): Select the intended PDF attachments-to-be in MS Windows Explorer and use SEND-TO to create the email. Then manually add one specific additional PDF attachment, add some text, format and colour this text with bolding and colour buttons, select the sender, etc. Save the whole thing to DRAFT and closed the window. When the email is opened, the email is irrevocably in plain-text format. Attachments are present, all text is plain, unadorned except for the plain-text *bolded-text* and _italics-text_ character highlighting. Case (b): Create the email with WRITE. Then manually add the intended common PDF attachments and -- now identical to above -- add one specific additional PDF attachment, add some text, format and colour this text with bolding and colour buttons, select the sender, etc. Save the whole thing to DRAFT and closed the window. When the email is opened, all HTML colouring and bolding are intact. Case (c) was never used -- I used attachments in both cases, no embedding for sure. (And I know this example has to work differently.)

Oh, you were talking about difference of "Save As Draft" between "SEND-TO" and "Write Message"... I could observe it in Tb 31.2.0 on Win. SEND-TO Write Msg 1. Start composition Composed in HTML Composed in HTML if used identity=HTML mode if used identity=HTML mode 2. Save As Draft Saved as text/plain Saved as text/html 3. Change identity then Save as Draft Saved as text/plain Saved as text/html 4. Send Later Depends on Auto-Detect, Depends on Auto-Detect, but if <B> is used, but if <B> is used, sent in HTML sent in HTML If invoked via SEND-TO, it looks that "Save As Draft" always saves draft mil as "text/plain". So, when SEND-TO, if mail composition is terminated after Save As Draft, HTML mode is lost upon next Edit Draft. Obviously, Tb's behavior is inconsistent.

A method to avoid your confusion : Composition mode of default identity of default account = Plain Text Once "mail composition by SEND-TO" is started in Plain Text mode, there is no way to change to HTML mode in Tb. If you want to change to HTML mode, you have to start new mail composition in HTML mode(=Write Msg) and do Paste. Therefore, confusion can not be produced by SEND-TO :-) I think "why many users didn't find this bug" is; - "default identity of default account" is also used in mail composition via mailto: link which is invoked by Browser. In this case, "compose in text/plain" is perhaps preferred widely. - If SEND-TO, majority of Tb users does do "Send at invoked composition window". "SEND-TO, Save As Draft, Quit composition, Edit Draft" is rarely used if user started mail composition via. SEND-TO. - When user want to attach a file to a mail, there are 3 ways. (i) Start mail composition first, and select attaching file, then attach file via Drag&Drop (ii) Start mail composition first, and go File/Attach menu, then select attaching file (iii) Select attaching file first, then start mail composition via. SEND-TO. Number of Tb users who loves (i) > Number of Tb users who loves (ii) >> Number of Tb users who loves (iii).

FYI. My comment #23 is answer to my question in comment #1 by myself, instead of from you :-) > For Case 1 - saved and re-opened > At which step was "HTML mode" actually lost in your case?

BUT !!!! The new summary description is too limiting. See Comment 0: It also messes up -- inconsistent -- even when you directly SEND the message! Create an email with attachment by SEND-TO, or by WRITE and add the attachment. Do the colours and bolding in each case, and then SEND the message. The incoming file at the recipient is plain text if it was created by SEND-TO, and normal (correct) HTML if it was created by WRITE. I recalled this happened unexpectedly when I recently sent a photo attachment to my laptop (which was out of town at the time so I couldn't check it). I had used SEND-TO to create the email -- I remember, because I had just created the image from PhotoShop and wanted to be sure I had the correct image. The reply came back in plain text (I could tell by the colour and font) which never happens on replies from the laptop. This send-and-reply was a TB-to-TB-to-TB exchange, both TB's current and as identical as possible in setup and configuration (which I later confirmed). There was nothing done along the way to cause plain text in this case that wouldn't have been done in hundreds of other transactions, some of which contain attachments, most of which contain bolding, italics, colours, etc. Very few were initiated by SEND-TO, and I can't say (because I don't know and never needed to check) how those were received. So there is something at the beginning of the process that differs between SEND-TO and WRITE -- and that something stays different all the way through to when you save/close/reopen or to when you send out. (And I mean create and send, not create/save/reopen and send.) @WADA - Thanks for the confirmation & setting the correct bug status flags.

@WADA - Comment #24... > Composition mode of default identity of default account = Plain Text > Once "mail composition by SEND-TO" is started in Plain Text mode, there is no way to > change to HTML mode in Tb. Then why does it LOOK like HTML mode? Background is white, not yellow; Formatting buttons work (I can add colour, bolding, italics, or change font); I can add links. > "default identity of default account" is also used in mail composition via mailto: link which > is invoked by Browser. > In this case, "compose in text/plain" is perhaps preferred widely. Why preferred widely? (i) If I was the webpage writer invoking a MAILTO, I might prefer to see the email come to me in HTML -- its best clothes, so to speak -- while recognizing I have to use what's available. (ii) But if I was clicking a MAILTO link on someone's webpage, I would *definitely* want to use HTML if at all possible -- it's my composer at that point, I want it to work my way. > When user want to attach a file to a mail, there are 3 ways. > (i) Start mail composition first, and select attaching file, then attach file via Drag&Drop > (ii) Start mail composition first, and go File/Attach menu, then select attaching file > (iii) Select attaching file first, then start mail composition via. SEND-TO. > Number of Tb users who loves (i) > Number of Tb users who loves (ii) >> Number of Tb users > who loves (iii). I agree! :) Personally, I have issues with Drag&Drop "losing" things (by moving vs copy, etc) and I shy away from it in most cases, so I right-click drag instead. And of course SEND-TO is more convenient in some cases (such as previewing/verifying/selecting.

(In reply to Dan Pernokis from comment #27) > Then why does it LOOK like HTML mode? Background is white, not yellow; > Formatting buttons work (I can add colour, bolding, italics, or change font); I can add links. Was mail composition window opened with the "default identity of the default account of mode=Plain Text"? "Initial composition mode" is not changed by identity change while composing. Please distinguish next. - Composition window started in HTML mode - Composition window started in HTML mode, Delivery Format=Auto-Detect(initial, always defaulted) - Composition window started in HTML mode, Delivery Format=HTML&Text or HTML Only - Composition window started in HTML mode, Delivery Format=Plain Text Only => No buttons for tag/format/layout, no insert image/table/link/... menu, But still can change Delivery Format. - Composition window started in Text mode => No buttons for formatng/layouting, no insert image/table/link/... menu, No way to change Delivery Format I also love SENDTO as a "method to attach files to a mail" instead of as "method to send files via. mail", because "directory/file selection at file picker by File/Attach" is annoying for me, and "Drag&Drop files from Windows Explorer"to attachment box position of an already opened compose window" takes long path - drag to task bar, drag to appeared compose window, drag to right of To: field to open attachment box, .... "Select files then open compose widow by SENDTO" is shortest way to attach files for me :-) This bug occurs in SeaMonkey too. I sometimes did "SENDTO/Save As Draft/Quit composition"/Edit draft", but my ordinal composition mode is Text Plain(if HTML mode is needed, do Shift+Write, Shift+Reply, Shift+Forward), so I couldn't be aware of "text/plain draft mail even when HTML mode, if invoked by SENDTO", although I'm long user of Netscape, Mozilla, Mozilla App Suit, SeaMonkey. I guess that logic like "SEND-TO=send in text/plain" is still alive in "Draft Save", even after "compose in HTML and send in HTML" is widely accepted and "default of composition mode-HTML" is done in Mozilla Mailnews/Thunderbird.

(In reply to Dan Pernokis from comment #26) > BUT !!!! The new summary description is too limiting. > See Comment 0: It also messes up -- inconsistent -- even when you directly SEND the message! Inconsistency in "attached file handling while composing" is already covered by Bug 378046. And, "directly SEND the message" part of your case is already covered by bugs listed in dependency tree for Bug 889315. (and, is pretty consistent : If Tb wants to send in Text, Tb sends in Text :-) ) What is difference between SEND-To and Write-Msg? As for Auto-Detect, and Auto-downgrade-to-Text, I couldn't be ware of difference between Send-To and Write-Msg. I could observe difference in "Save As Draft" only. For reply from someone including yourself to mail composed by you using SEND-TO: - Format of Reply mail depends on: Compose format settings in Tb - Used part in Reply depends on View/Message Body As : - Message Body As = Plain Text : text/plain part, or text converted from text/html if no text/plain - Message Body As = HTML : text/html part, or text/plain if no text/html - Format of Reply mail depends on "Shift key is pressed upon Reply, or not". "Shitt" == Use opposit of defaulted composition mode This kind of difference is main reason why I don't refer to other than "new mail composition". "Final sent format" is affected by all of "original mail format sent by you" and "composition mode of used identity upon start of reply mail composition" and "View/Message Body As" and actions taken by Reply mail sender upon/while composing the Reply mail. > The incoming file at the recipient is plain text if it was created by SEND-TO, > and normal (correct) HTML if it was created by WRITE. "Copy of sent mail by you" is usually saved in Sent folder. If the "Copy of sent mail by you" is available, you can see sent format merely by "View Message Source". Even before actual "send to recipients via. SMTP server", you can see "final sent format" by "Send Later", "View Message Source at Outbox" followed by "Send Unsent Messages at Outbox". Was the mail actually sent in what format by you? Please note: In mail display by Tb, View/Message Body As is applied. This is global option in a Thunderbird instance So, if View/Message Body As/Plain Text, sent mail/draft mail is shown in Plain Text mode, even when sent/written in HTML. As it seems "Relevant mailers is Thunderbird only", and as it seems that "composition mode of all identities of all accounts in all Thunderbird profiles" is HTML mode, I guess "Reply mail was composed in HTML mode upon start of composition". However, all of Auto-Detect, Auto-downgrade-to-Text, Send Options setting, Delivery Format choice upon send, are applied to the Reply mail composed at a Thunderbird instance too. Please note again that Tb's Auto-Detect sends in Text when Tb's Auto-Detect wants to send in Text :-) > So there is something at the beginning of the process that differs between SEND-TO and WRITE It's right. If no difference, "difference in Save As Draft" can not be explained. Tb knows about "composition is invoked via. MAPI". However, I can't see difference nor inconsistency in "Sent format after Auto-Detect processing by Tb". Question again. What is actual difference or actual inconsistency between SEND-To and Write-Msg in "final sent format by Tb" in your case?

Hi Dan, thank you for your valuable feedback and discussion of problems in the user experience (UX) around the delivery format when sending messages. I don't have time nor energy for reading all the details, but as one of TB's key QA and UX contributors I'd like to register my emotional and factual support for the UX issues you are seeing, because they are real issues and your concerns are valid. However, as you'll notice /especially/ when corresponding with WADA who is very versed about the behaviour but sometimes a bit harder to understand (or to figure out the social undertones of where he stands...), the underlying problems are very complex as there are so many settings involved and different ways of doing things, so it's easy (even for a highly experienced person like WADA, see comment 23) to overlook a tiny thing which will in turn lead to different claims about the behaviour. That's why I created delivery format UX tracker bug 889315 so that there's a central access point for all problems around this issue, and we can try to understand the interaction / common denominator of all those problems better. However, the complexity doesn't end in TB's settings, different code paths depending on usage patterns, and plain bugs in TB's behaviour. You're also seeing the remnants of history where when HTML messaging was introduced, it caused problem to some users who were on low-bandwidth connections, with text-only email clients, very small storage capacities etc. At that time, there was a war between supporters of plaintext messaging and HTML messaging. The war is over, and HTML won as a default, while TB is still kind enough to offer plaintext as a fully implemented alternative format for the minority who prefer that. However, again history, there was an important developer who as a war veteran until recently has defended his obvious bias for enforcing plaintext tooth and nails against all user complaints, UX principles and common sense, and also had the power to implement the broken and unpredictable design some of which has still survived to this day. Add to that the struggle of TB as an underestimated, chronically underfunded, ultimately defunded Mozilla product, resulting in even less leadership and even less chances to get old and complex bugs fixed... (Good news being that we've started processes to restore community leadership and funding...) FTR, here's my take on this: TLDR: * {Delivery Format > Autodetect} sucks (as an unpredictable, misbehaving and buggy default forced on everyone) and really has outlived its purpose in a web world ruled by HTML. * If in doubt, we should always err in favor of HTML to avoid dataloss of formatting (e.g. unknown/collected recipients must be assumed to prefer HTML until user explicitly defines otherwise). Those who really still need/want plaintext are free and can be expected to explicitly choose that. * We need to respect UX-wysiwyg at all times: If I compose in HTML, whatever I see in my composition should be sent with exactly the same underlying HTML source as composed and seen on-screen. Sending HTML ensures the highest possible perservation of the intended formats for the view of recipients. * Different UI methods of doing the same action should never yield different behaviour or results. Wrt this bug, it's clearly wrong when (using HTML default account) using Send-To (MAPI) vs. other NON-MAPI methods of composing lead to different delivery formats. Same for attachments, the method of attaching must never influence attaching behaviour wrt editing attachment/time of attaching. More specifically (potentially covering some points you mentioned): * Per current mis-design, depending how and where you apply your HTML/CSS formatting, it will either be preserved by Auto-Detect or not. E.g. any CSS formatting via style attributes on a number of tags who are wrongly deemed negligable will unexpectedly get dumped upon sending. * If some of your recipients in AB are marked as "prefers-plaintext" or "prefers-unknown", TB used to stubbornly decide for plaintext-only delivery for everyone even those marked "prefers-html" (although I think we recently improved on that). I believe we have most but probably not all of these things on record as bugs (see bugs in the "Depends-on" field of bug 889315); unfortunately some attempts to file and pursue respective bugs were ruthlessly crushed and morphed away by the plaintext war veteran mentioned above. Nowadays I think we'd be able to agree on and follow through with a better UX more easily, but it's more a matter of lacking volunteer developer time (more so in view of the complexities in design and code). Again, thank you for your valuable time to help and improve Thunderbird UX.

Dan, in support of WADA's efforts to clarify and limit the scope of this bug, we/you really need to observe the one-issue-per-bug principle. Some of the issues you mentioned here are certainly true but we can't track them here in this very bug, because they are technically different from the core issue of this bug. Our only chance to ever get these things fixed is to break them up into smaller and concisely-defined parts which can be fixed by developers. Again, if you check on the meta bug 889315 you'll probably find most of your issues listed as separate bugs. Keep that in mind to avoid confusions, as WADA is very strict about keeping technically separate bugs separate (and rightly so!), even when from user's less informed pov, they might look related or same issue. So WADA will (correctly) keep firing questions at you as long as you claim it's just the same issue which should be covered here while technically and in terms of bug management, it's probably not and it shouldn't... ;)

I can confirm this bug on TB 31.2.0 basically as described in comment 0 and comment 23. We should test if this also happens in TB 24 or TB 3; might be a regression? However, actual result of comment 0 is fuzzy, and the actual problem of this bug is not clear enough in comment 23. So let's try again: STR 0 Ensure that the default identity of your default account is set to "Compose messages in HTML format" (Account settings, Composition and Addressing) 1a On Windows, from explorer's file context menu, choose "Send to > Email Recipient" (using MAPI) 1b For comparison, in main 3pane, select default account and click "Write" (optionally add an attachment, but it won't make a difference) 2 Apply HTML formatting using the formatting toolbar, e.g. <b> For full devestating effects, add plenty of formatting, headlines, colors, inline pictures, links etc. 3 Ctrl+S to save as draft, and close draft ("let me continue this formatted mail tomorrow") 4 Re-open draft from drafts folder Actual result 3a (Send-To, saving draft) Message is silently downconverted to plaintext when saving (but still intact in composition window, even upon sending if you don't ever close the composition window, contrary to comment 0) 4a (Send-To, Re-editing draft): - Curse TB because ALL your formatting is gone (including images) AND - you cannot even reapply any formatting because you are stuck in plain-text editor with no way out (bug filed) Depending on how much work you've invested in your formatting, that's substantial and non-recoverable dataloss of formatting, images etc. -> Dataloss -> Critical 3b (Write, saving draft) Message is correctly saved as HTML 4b (Write, re-editing draft) Message is correctly re-edited as HTML with full formatting Expected result 3a (as currently happens in 3b, even without formatting applied): Saving a message composed in HTML mode should NEVER save plaintext unless explicitly requested (which automatically solves 4a: Formatting and editing mode must be preserved across closing and re-editing drafts, as in 4b)

Difference in compose window opened with HTML mode. > Opened by SEND-TO : window.gMsgCompose.compFields.forcePlainText = true > Opened by Write Msg : window.gMsgCompose.compFields.forcePlainText = false > note: window.gMsgCompose.compFields.useMultipartAlternative = false in both cases. Code lines refers to forcePlainText > http://mxr.mozilla.org/comm-central/search?string=forcePlainText gMsgCompose.compFields.forcePlainText = true is perhaps set by one of next in SEND-TO case. (a) nsMapiHook::PopulateCompFields > 366 // this is used to populate comp fields with Unicode data > 367 nsresult nsMapiHook::PopulateCompFields(lpnsMapiMessage aMessage, > 368 nsIMsgCompFields * aCompFields) > > 437 if (Body.Find("<html>") == kNotFound) > 438 aCompFields->SetForcePlainText(true); (b) nsMapiHook::PopulateCompFieldsWithConversion > 557 // this is used to convert non Unicode data and then populate comp fields > 558 nsresult nsMapiHook::PopulateCompFieldsWithConversion(lpnsMapiMessage aMessage, > 559 nsIMsgCompFields * aCompFields > > 643 if (Body.Find("<html>") == kNotFound) > 644 aCompFields->SetForcePlainText(true); Because "passed text as message body text from Windows" is simple text(no <html> in text), gMsgCompose.compFields.forcePlainText = true is set by nsMapiHook. However, mail composition window is opened in HTML mode because "composition mode of used identity" = HTML. "Save As Drafts" perhaps looks gMsgCompose.compFields.forcePlainText. It looks that gMsgCompose.compFields.forcePlainText is also set from "HTML or Plain Text preference in Address Book", and it looks referred in "Mail Send" code. So, "difference in SEND-To and Write-Msg" can be produced by "difference in window.gMsgCompose.compFields.forcePlainText is true or false", but I'm not sure.

@THOMAS D... Comment #32 is bang on -- See my Comment #3 where I did re-test using a direct SEND and it appeared to work normally. I can't swear about the circumstances of the original SEND that I am suspicious of (photo to the laptop and reply) -- it may well be that it was saved and re-opened. [[ There is an irritating Windows quirk for which TB is especially susceptible -- losing the ASCII character set sometimes, where quote characters must be struck twice, pound becomes slash, garbage like that. The quick solution is to save your msg & close, quit TB, then relaunch. So having done a save is quite possible even though unintended and not remembered. ]] I did re-test today -- with and without WADA's suggested "ffffe" fix. I used SENT-TO to create three emails and plastered them with random bolding, colours, and italics. First email was SAVE'd only -- and it lost its formatting (as we know). Second email was SEND'd directly (to myself). Third email was SAVE'd, and then SEND'd (not closed). Both sent messages arrived with HTML intact, so I'll agree that the SEND part of my complaint is not valid. I know you don't need more complexity but I offer the following as a tracer/teaser to confirm or disprove certain internal workings: In my rant in Comment #6... > It was easy to click/select the common documents in Explorer and SEND-TO them to email recipient, > < do various edits >, SAVE to draft, then clone the saved message several times, open them, > and finally add the recipient-specific attachment and specific wording to each message. In other words, I saved the first message to Draft for use as a template, copied it in Draft to make several copies, then click-selected and OPEN'd the copies to do recipient-specific edits. Point is: ALL CLONES also suffered from plain-text fever, so whatever settings are saved in the draft DO propagate when copied. Finally, your Comment #30 is *MUCH* appreciated -- provides good historical perspective, and last half gives me great confidence that the issue is fully understood and will eventually be resolved. And thanks for the major escalation.

@WADA - Comment 33... > It looks that gMsgCompose.compFields.forcePlainText is also set from "HTML or Plain Text > preference in Address Book", and it looks referred in "Mail Send" code. Not sure if I told you, but virtually ALL of my address book entries are set to "Unknown" preference, since (i) "Unknown" is the default when created deliberately, and (ii) "Unknown" is the setting used if "collected".

(In reply to Dan Pernokis from comment #35 > > It looks that gMsgCompose.compFields.forcePlainText is also set from "HTML or Plain Text > > preference in Address Book", and it looks referred in "Mail Send" code. > Not sure if I told you, (snip) I wanted to say; - I can explain "Difference between SEND-TO and Write-Msg" in "Save As Draft" by "difference of compFields.forcePlainText". - I still can NOT explain "Difference between SEND-TO and Write-Msg" on "Sent mail format" in "Direct Send of youe case" by "difference of compFields.forcePlainText". - I still can't reproduce your "Difference between SEND-TO and Write-Msg on Sent mail format in Direct Send". I could observe is : If Preference of message format of a Contact in Address Book == Plain Text, and if To: is the "Contact in my address book" only, and if Delivery Format=Auto-Detect(default) is used, message composed in HTML with <body bgcolor="#99FFFF" text="#FF00FF">, <B>, <table>, <a> <img>, ... , is sent as text/plain by Auto-Detect of Tb without asking about "send format" to me, even when I set Tools/Options/Composition/Send Options/Text Format = "Ask me what to do", regardless of SEND-TO or Write-Msg. This is current intentional design/implementation of "format preference of a Contact=Plain Text". Bug 584363 is for issues in "Preference=Unknown Contact" and "mail address which is not registered to address book". Because you set Tools/Options/Composition/Send Options/Text Format = "Send both HTML and Plain Text", and because sme From: and same To: is used in your test, regardless of SEND-TO or Write-Msg, "mail composed as HTML" should be sent as multipart/alternative{text/plain+text/html} if <B> is used, even when Delivery Format=Auto-Detect(default) is used, unless all recipients is "Contact of format preference=Plain Text in address book" or "Text Domain" setting is used by you.

(In reply to Dan Pernokis from comment #35) > virtually ALL of my address book entries are set to "Unknown" preference, > since (i) "Unknown" is the default when created deliberately, > and (ii) "Unknown" is the setting used if "collected". FYI. I also usually tested with bgcolor="#99FFFF", with recipient=Unknown or recipient=Not registered to address book, with Delivery Format=Auto-Detect, with Send Options/Text Format = "Send both HTML and Plain Text". When Send Options/Text Format is changed to "Ask me", upon "Send Later", Tb 31.2.0 on Win asked me for Send format with second "Send in Plain Text" pre-checked, regardless of HTML mail composition request type : SEND-TO or Write-Msg. i.e. "When send in HTML" is always applied by Thunderbird to both SEND-TO and Write-Msg in my test. i.e. If bgcolor="#99FFFF" is used, mail is always sent as HTML by Send Options/Text Format = "Send both HTML and Plain Text" in both SEND-TO case and Write-Msg case, if I tested in my environment using my Thunderbird. (As Thomas D. says, it seems that part of problems cited in Bug 584363 is already resolved and improved. It seems that "Unknown!=HTML -> Unknown=Text" is already removed. It seems "Unknown == !HTML&&!Text" as expected in recent Tb.)

FYI. If mailto: link, when "compose mode of default identity of default account" = HTML, composer is opened in HTML mode with following compFields properties, so "Save As Draft" saves draft mail as text/html, even when Delivery Format is changed to "Plain Text Only". > Opened by mailto : window.gMsgCompose.compFields.forcePlainText = false > Note-1 : window.gMsgCompose.compFields.useMultipartAlternative = false > Note-2: mailto: link is passed via OS integration(thunderbird.exe -compose ...) "Still alive thing" looks "Send To == send files using text mail" in MAPI support of Thunderbird. If "Send To === send files using text mail" is still correct, proper, valid, "what is wrong in Thunderbird" is "open composer in HTML mode even though requested via Send To && requested with forcePlainText=false".

Oh, you had written as follows... Your comment #34. > I did re-test today -- with and without WADA's suggested "ffffe" fix. > I used SENT-TO to create three emails and plastered them with random bolding, colours, and italics. > First email was SAVE'd only -- and it lost its formatting (as we know). > Second email was SEND'd directly (to myself). > Third email was SAVE'd, and then SEND'd (not closed). > Both sent messages arrived with HTML intact, > so I'll agree that the SEND part of my complaint is not valid. But your comment #26 was as follows. This is never "COMPLAINT". This was your report on "phenomenon actually occurred in your environment", wasn't this? comment #34 is simply "different result by different test or actions", isn't it? > Create an email with attachment by SEND-TO, or by WRITE and add the > attachment. Do the colours and bolding in each case, and then SEND the > message. The incoming file at the recipient is plain text if it was created > by SEND-TO, and normal (correct) HTML if it was created by WRITE. > > I recalled this happened unexpectedly when I recently sent a photo > attachment to my laptop (which was out of town at the time so I couldn't > check it). I had used SEND-TO to create the email -- I remember, because I > had just created the image from PhotoShop and wanted to be sure I had the > correct image. The reply came back in plain text (I could tell by the > colour and font) which never happens on replies from the laptop. > > This send-and-reply was a TB-to-TB-to-TB exchange, both TB's current and as > identical as possible in setup and configuration (which I later confirmed). > There was nothing done along the way to cause plain text in this case that > wouldn't have been done in hundreds of other transactions, some of which > contain attachments, most of which contain bolding, italics, colours, etc. > Very few were initiated by SEND-TO, and I can't say (because I don't know > and never needed to check) how those were received. > > So there is something at the beginning of the process that differs between > SEND-TO and WRITE -- and that something stays different all the way through > to when you save/close/reopen or to when you send out. (And I mean create > and send, not create/save/reopen and send.)

@WADA - Reply to Your Comment #39 (re SENT-TO and sending)... I had "complained" because the flip to plain-text when sending after a SEND-TO was being excluded from the bug description. But I have since come to realize -- as was pointed out various ways -- that it DOES work correctly on send. See my Comment #3 - I couldn't say with confidence that it was or wasn't working. And in Comment #34, I'm officially backing down because I see it does work -- and I explained what may have happened: > See my Comment #3 where I did re-test using a direct SEND and it appeared to work normally. > I can't swear about the circumstances of the original SEND that I am suspicious of (photo to > the laptop and reply) -- it may well be that it was saved and re-opened. [[ There is an > irritating Windows quirk for which TB is especially susceptible -- losing the ASCII character set > sometimes, where quote characters must be struck twice, pound becomes slash, garbage like that. > The quick solution is to save your msg & close, quit TB, then relaunch. So having done a save > is quite possible even though unintended and not remembered. ]] I have concrete proof that the format had changed to plain-text -- but nothing solid on procedure. I THOUGHT it had been sent directly (SEND-TO, add some text, send) -- but I now realize i MIGHT have saved/closed/re-opened before sending (which would have lost the formatting in the close/open) because of the character-set quirk. As I said, I may have done it without intending (so without remembering). My mind linked the two problems because of the known commonality -- using SEND-TO -- and I presumed I had not saved this one because it was a simple email. On looking at it again now, I see it is loaded with quote symbols and other extended/special ASCII characters that screw up regularly -- so I wouldn't surprised if I had saved & closed to quit TB and relaunch.

(In reply to WADA from comment #38) > FYI. > If mailto: link, when "compose mode of default identity of default account" > = HTML, composer is opened in HTML mode with following compFields > properties, so "Save As Draft" saves draft mail as text/html, even when > Delivery Format is changed to "Plain Text Only". > > Opened by mailto : window.gMsgCompose.compFields.forcePlainText = false > > Note-1 : window.gMsgCompose.compFields.useMultipartAlternative = false > > Note-2: mailto: link is passed via OS integration(thunderbird.exe -compose ...) Thank you for detailed analysis. So even mailto: uses text/html, which is further proof of the inconsistency seen in this bug, and for the required solution of using .forcePlainText = false or whatever is needed to enable saving as HTML (especially when user generally composes in HTML; if user's default compositions use plaintext mode, plaintext for mailto: and send-to would probably be OK. However if in doubt, or technical problems, we need to err in favor of HTML where user can still manually choose plaintext for sending if he so wishes, but not vice versa). > "Still alive thing" looks "Send To == send files using text mail" in MAPI > support of Thunderbird. > If "Send To === send files using text mail" is still correct, proper, valid, > "what is wrong in Thunderbird" is "open composer in HTML mode even though > requested via Send To && requested with forcePlainText=false". I think there's an unintended mistake here, what you say only makes sense if corrected like this: > If "Send To === send files using text mail" is still correct, proper, valid, > "what is wrong in Thunderbird" is "open composer in HTML mode even though requested via Send To && requested with forcePlainText=*true*". WADA, I generally appreciate objective analysis considering all potentially possible theoretical views of a problem (and I try to do that before I suggest UX solutions), but sometimes making all hypothetical views explicit can cause more confusion and distraction than benefit. I think it's beyond doubt that at least for default settings (which is compose-in-html), "Send To === send files using plaintext mail" can NEVER be correct, proper, valid, for the following reasons: 1) Allowing users to properly format their messages with fonts, font styles, headlines, links, color, images, real tables, etc. is obviously useful for written communication because such formatting helps to add structure and value to the content; such precise and versatile formatting is never possible with plaintext. 2) Hence since long back, TB has taken a decision to use HTML as default format for mail messages (while still offering plaintext as an option for the minority who need/care about this) 3) Given 2), for default settings it would clearly break UX-consistency when we suddenly force users into plaintext composition just because he starts out from Windows Send-to (while all other ways of composing use HTML). 4) Worse, due to other bugs, plaintext composition can never be directly upgraded into HTML composition, so presenting the plaintext composer actually *forces* users to stick with plaintext for that message short of restarting from scratch, both of which (forcing them into plaintext or expecting them to restart the msg with other methods) is clearly unacceptable. For the sake of moving forward more efficiently, perhaps we/you can try to skip theoretical scenarios which will not be implemented as they are not sustainable from an UX/design POV. Your personal opinion is not always clear (perhaps because you want to stay "neutral", or because some of your intended hints are too subtle to note, or perhaps partly due to language issues), but I think even you yourself are not suggesting that we should really force default users to get stuck in plaintext composition when they use Send-To. And to be clear about my position, if there's no better solution or if better solution is too much work, I would not hesitate to fix this bug by creating minor inconsistency for the minority of plaintext-composition users by presenting them with HTML composition, which is clearly the lesser evil for all the reasons mentioned above. That's much less of a problem because HTML composition can always be downgraded to plaintext, but plaintext composition (due to bugs) can never be upgraded to HTML.

Rewrite my comment for Thomas D. > If "Send To === send files using TEXT mail" is still correct, proper, valid, > "what is wrong in Thunderbird" is > "open composer in HTML mode even though requested via Send To && requested with forcePlainText=*true*". > However, even if defined by MS, normal definition is "Send To == send files using mail", isn't it? > Even if definition by MS is such one, why compFields.forcePlainText = false is set by nsMapiHook when body has <html>? > Why "forcing Plan Text mode if Send To" is still needed? Simplest/easiest solution is; Don't do "aCompFields->SetForcePlainText(true);" in nsMapiHook::PopulateCompFields and nsMapiHook::PopulateCompFieldsWithConversion I guess what happened was: 1. "aCompFields->SetForcePlainText(true) by nsMapiHook" was done in order to avoid HTML mode composition when Send To. If "Send To", "HTML mode composition" was limited to "when body text has <html>" case only. 2. In this era, compFields.forcePlainText = true/false was used to determine draft format, and is still used by "Save As Draft". 3. After it, "Mail composition mode selection" was changed to "determine mode by identity's mail composition mode setting". 4. And, Auto-Detect was introduced and improved. Even though "automatic downgrade to Text" is still alive, as far as "automatic downgrade to Text" is not applied to a mail composed in HTML, "Sent mail format of mail composed in HTML" is always determined by Send Options/Text Format as expected. - If (all recipients==prefers Plain Text), silently send text/plain part only. - If !(all recipients==prefers Plain Text), send format is determined by Send Options/Text Format. I can't call it "Mistake", although I think "mismatch between features for different purposes" should have been removed earlier. I believe that there is no need to force compFields.forcePlainText=true when Body doesn't have <html> by nsMapiHook any more.

(In reply to Dan Pernokis from comment #40) You perhaps simply saw "automatic downgrade to Text" and it perhaps merely was when you used Send-To in the past. It's pretty ordinal phenomenon unless you perfectly kill Tb's "Tb sends in Text when Tb wants to send in Text" :-) To achieve "when composed in HTML, always sent in HTML in Tb", following is needed. (a) Skip "automatic downgrade to Text of Tb". (a-1) Workaround of <B>, bgcolor!=#FFFFFF, color!=#000000 etc. (a-2) Install "Always HTML" add-on. I recommend (a-2). (b) Don't set "preferred format = Plain Text" for any Contact in your any address book. If recipients are "preferred format = Plain Text" only, Tb sends text/plain part only in multipart/alternative{text/plain+text/html} as text/plain mail. If recipients are "preferred format = HTML" or "preferred format = Unknown" or "mail address is not in address book" or mixture of these three types, "When sending in HTML" is effective. (c) Don't use "Plain Text Domain" setting, if it's not needed for you. (d) By (a) and (b) and (c), "When sending in HTML" of "Send Options/Text Format" is applied to any mail composed in HTML. So, Send Options/Text Format="Ask me" or "Both HTML and Text" or "HTML Only" is always applied to any HTML mail. Because "preferred format = "Plain Text"/"HTML"/"Unknown" was introduced and it's already sorted out and works as expected, and because there is "Plain Text Domain" setting, I think "automatic downgrade to Text" is not needed any more. But it's different issue or theme.

FYI. When "Save As Draft", "Code for send" is shared with "final Send"/"final Send Later". "Format of draft" is perhaps determined at here. > 1518 nsMsgComposeAndSend::GetBodyFromEditor() > 1593 rv = nsMsgI18NSaveAsCharset(mCompFields->GetForcePlainText() ? TEXT_PLAIN : TEXT_HTML, > 1594 aCharset, bodyText, getter_Copies(outCString), nullptr, &isAsciiOnly); If "final Send"/"final Send Later", msgCompFields.forcePlainText and msgCompFields.useMultipartAlternative is perhaps set(changed) at here, according to "mail composition mode" and "Send Options/Text Format setting" and "preference of mode in Address Book of each recipient". > http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2726 This is perhaps trick of "mail is sent in HTML even when draft is saved as text/plain due to msgCompFields.forcePlainText=true which is set by nsMapiHook. Another possibly correct solution : When Tb invokes composer in HTML mode, set msgCompFields.forcePlainText=false explicitly, regardless of current msgCompFields.forcePlainText value which may be set by nsMapiHook. This is code change in composer according to change to "mail composition mode is determined by identity setting". This is code in composer to avoid "mismatch between draft format and mail composition mode" which may be produced due to unwanted/unexpected msgCompFields.forcePlainText=true by someone like nsMapiHook.

Arivald, does your "Always HTML" addon fix this, too? Guess it might... Pls follow STR of comment 32 exactly. Tia.

Here's a tentative patch along WADA's analysis of Comment 33 et alii. We (Wada and I) understand that the current code checks if the body of the message passed via windows MAPI already has a <html> attribute, which is never the case for Window's send-to command. So that check is nonsense, to say the least. So I just ripped this out, hoping it might fix the issue per WADA's analysis. I can't test this, for I don't build. Can somebody try please, following STR of comment 32 exactly? > - if (Body.Find("<html>") == kNotFound) > - aCompFields->SetForcePlainText(true); This might have side effects (say for users who relied on this blind guess to force plaintext via MAPI), although I don't expect any, and I wouldn't care much because the current code is definitely the wrong approach if it does what we think it does. Interestingly, we don't even preserve the user-selected delivery format in message drafts across closing and reopening drafts, which is another bad bug.

@Thomas D. (reply to Comment 47) >> This might have side effects (say for users who relied on this blind guess >> to force plaintext via MAPI)... I don't think anyone can rely on the blind guess -- it's impossible -- because what-you-see is not what-you-get. It may look like HTML is active, but it dies out when SAVE'd and re-opened, or when SEND'd out to someone.

(In reply to Dan Pernokis from comment #48) > @Thomas D. (reply to Comment 47) > >> This might have side effects (say for users who relied on this blind guess > >> to force plaintext via MAPI)... > > I don't think anyone can rely on the blind guess -- it's impossible -- > because what-you-see is not what-you-get. It may look like HTML is active, > but it dies out when SAVE'd and re-opened, or when SEND'd out to someone. +1, that's very true. However, I saw "Send without UI" in the code, so for some edge cases of sending plaintext unattendedly it might have worked "reliably", but that behaviour should be made explicit instead of implicit. But even if there was currently no other way of forcing plaintext for the unattended scenario, fixing this major fallout would be more important than those advanced edge cases. Perhaps my bug 1202165 might help here, too, allowing for stable delivery format flags in the draft.

Comment on attachment 8657476 [details] [diff] [review] Patch v. 1.0: Don't set forcePlainText=true when MAPI passes plaintext body Review of attachment 8657476 [details] [diff] [review]: ----------------------------------------------------------------- This patch doesn't apply, which makes it hard to review, considering that MAPI is code I cannot review without having to run manual tests.

Correction on following phenomenon. (a) if Tb considered HTML mail can be silent converted to Text by Tb without user's permission or request, (b) Tb sends the mail composed in HTML by user as text/plain silently, without user's permission or request. When condition of (a) is true, (c) if true =="All recipients prefers HTML", sent as text/html(b doesn't occur). When condition of (a) is true, (c) if false=="All recipients prefers HTML", sent as text/plain(b occurs). i.e. When condition of (a) is true, action of (b) is done by Tb unless all recipient's prefs is set to HTML. Sorry for my confusion. Because your message preference setting is Unknown, if condition of (a) is true, (b) always occurs. So, majority of your "SEND-TO mail is composed in HTML but is sent as text/plain when Draft Save is not done" is above phenomenon, because you don't use many formating by HTML tag then condition of (a) is true in your many cases. Abobe phenomenon/issue is already well known and already processed in other bug. To bug opener and coment posters, please surely/clearly separate next cases. (1) SENDTO => composed in HTML mode because chosen identity's composition mode=HTML => Save As Draft => Saved as text/plain => When Edit Draft, always Text mode because text/plain mail (2) SENDTO => composed in HTML mode because chosen identity's composition mode=HTML => Save As Draft is not executed => condition (a) == true, => sent as text/html because true=="all is preferHTML" (3) SENDTO => composed in HTML mode because chosen identity's composition mode=HTML => Save As Draft is not executed => condition (a) == true, => sent as text/html because false=="all is preferHTML" (2)/(3) is absolutely different problem from (1), even if "SENDTO" and "sent as text/html or sent as text/plain" is involved in all problems. I believe problem newly discovered by you is (1) and is (1) only(==issue stated in current bug summary).

Comment on attachment 8657476 [details] [diff] [review] Patch v. 1.0: Don't set forcePlainText=true when MAPI passes plaintext body I think that what MAPI code wants to do(or should do) is "Force HTML mode, regardless of identity's composision mode, if body starts with <html>", instead of "Force Text mode if body doesn't have <html>".

This addresses Joshua's comment 50. Todo comment in code for WADA's Comment 52.

Joshua, I know that this review (requested one month ago) is #7 out of 11 in your review queue... However out of those, this bug is the only one marked critical (full dataloss of all message formatting, inline images etc.), so it should get higher priority. The good news, patch attachment 8677724 [details] [diff] [review] here is just an obvious one-liner (remove one line which clearly does the wrong thing), which has been pre-analysed and suggested by WADA. The other reviews in your queue look much more complex... ;)

Comment on attachment 8677724 [details] [diff] [review] Patch V.2: Don't set forcePlainText=true when MAPI passes plaintext body [Approval Request Comment] Regression caused by (bug #): User impact if declined: Messages started from Windows Explorer's SEND TO command can lose all formatting Testing completed (on c-c, etc.): Risk to taking this patch (and alternatives if risky): Zero. We just stop forcing plaintext where we must not force it. This critical dataloss bug has been waiting for Joshua's review for more than a year, which looks like a workflow failure. Jörg, please have mercy on this patch which removes one line which is obviously wrong as it can cause unexpected dataloss lateron... This should be uplifted to TB 52, too!

I'm having trouble looking at this due to bug 393302 comment #17, but I'll get to it in less than a year ;-)

OK, I can start a local debug build now to look into this. One needs to set this registry key: [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{29F458BE-8866-11D5-A3DD-00B0D0F3BAA7}\LocalServer32] ""="\"C:\\mozilla-source\\comm-central\\obj-x86_64-pc-mingw32\\dist\\bin\\thunderbird.exe\" /MAPIStartup"

Comment on attachment 8677724 [details] [diff] [review] Patch V.2: Don't set forcePlainText=true when MAPI passes plaintext body Review of attachment 8677724 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/mapi/mapihook/src/msgMapiHook.cpp @@ +435,5 @@ > if (Body.Last() != '\n') > Body.AppendLiteral(CRLF); > > + // Todo: Here we should force HTML composition mode if (Body.Find("<html>") == [snip]) > + // for scenarios where user's default account is set to plaintext editor. I don't like this comment for many reasons: 1) We use XXX TODO to mark spots of interest ;-) 2) What does [snip] mean? You mean: if (Body.Find("<html>") != kNotFound) ? 3) Why do we put a "to do" and not just fix it now? 4) How would you produce a case where HTML is found? I used |Sent to > Mail recipient| and that creates a message with a pre-canned text and an attachment. How would I get <html> into the pre-canned text? Either make the comment useful, lose it or implement what's needed. @@ -435,5 @@ > if (Body.Last() != '\n') > Body.AppendLiteral(CRLF); > > - if (Body.Find("<html>") == kNotFound) > - aCompFields->SetForcePlainText(true); I assume this will fix the bug.

Comment on attachment 8677724 [details] [diff] [review] Patch V.2: Don't set forcePlainText=true when MAPI passes plaintext body Clearing the review request for now since this is awaiting answers. You can ask for Aurora uplift after landing.

(In reply to Jorg K (GMT+1) from comment #59) > Comment on attachment 8677724 [details] [diff] [review] > Patch V.2: Don't set forcePlainText=true when MAPI passes plaintext body > > Review of attachment 8677724 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: mailnews/mapi/mapihook/src/msgMapiHook.cpp > @@ +435,5 @@ > > if (Body.Last() != '\n') > > Body.AppendLiteral(CRLF); > > > > + // Todo: Here we should force HTML composition mode if (Body.Find("<html>") == [snip]) > > + // for scenarios where user's default account is set to plaintext editor. > > I don't like this comment for many reasons: You're putting a lot of emphasis on a simple comment... How about starting out with "Thanks for this patch!" or "Thanks for fixing this dataloss bug!" ? 1) We use XXX TODO to mark spots of interest ;-) Yeah, this patch was written before you pointed out that syntax; fixed todo comment syntax is certainly helpful, and I'll try to remember, but honestly I think it doesn't matter much. Maybe the person landing the patch could also just fix it as a courtesy to the volunteer patch provider. > 2) What does [snip] mean? > You mean: > if (Body.Find("<html>") != kNotFound) ? Yes. > 3) Why do we put a "to do" and not just fix it now? I have no idea if or how it can be fixed and it's beyond the scope of this bug. > 4) How would you produce a case where HTML is found? > I used |Sent to > Mail recipient| and that creates > a message with a pre-canned text and an attachment. > How would I get <html> into the pre-canned text? Gegenfrage: Why do we have a check for <html> here at all? I think the existing check assumes that <html> is possible in the template passed via MAPI. It's obviously possible because certainly there are ways of customizing the pre-canned text, or other ways of using MAPI to pass in <html>. > Either make the comment useful, lose it or implement what's needed. Let's not forget that this is unpaid volunteer work. The comment is much less important than fixing this bad dataloss bug. I guess a responsible paid programmer should just take the patch and land it, instead of wasting energy and cycles on a comment. > @@ -435,5 @@ > > if (Body.Last() != '\n') > > Body.AppendLiteral(CRLF); > > > > - if (Body.Find("<html>") == kNotFound) > > - aCompFields->SetForcePlainText(true); > > I assume this will fix the bug. Indeed, that's what we're here for. Bad enough that we've exposed users for so long, so please let's just get done with this. I think I've done my part by offering the patch code, the rest can easily be done by others.

I've done some research into the pre-canned message "Your message is ready to be sent with the following file or link attachments:". Apparently this is hard-coded into Windows since XP. Many users complain about not being able to get rid of this text or configure it, for example: http://forums.mozillazine.org/viewtopic.php?f=28&t=380960 I don't see how we would ever get a <html> tag in the pre-canned message, so we can just lose the comment which suggests that there might be further work to do here. As a responsible paid reviewer I've tested the patch after setting the following registry keys to point to my locally compiled version: [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{29F458BE-8866-11D5-A3DD-00B0D0F3BAA7}\LocalServer32] ""="\"C:\\mozilla-source\\comm-central\\obj-x86_64-pc-mingw32\\dist\\bin\\thunderbird.exe\" /MAPIStartup" [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Mozilla Thunderbird] @="Mozilla Thunderbird" "DLLPath"="C:\\mozilla-source\\comm-central\\obj-x86_64-pc-mingw32\\mailnews\\mapi\\mapiDLL\\mozMapi32.dll" I've tested with both HTML and plaintext composition. In the former case, the pre-canned text is placed into a HTML composition, in the latter case into a plaintext composition. Obviously the forced downgrade is removed. So thanks Thomas for tracking this down and thanks for the persistence. Let's take this to Aurora, so it goes into TB 52 ESR.

Comment on attachment 8821180 [details] [diff] [review] Patch V.2.1: Don't set forcePlainText=true when MAPI passes plaintext body - removed comment Actually, this can go into TB 51 beta, too, which we haven't built so far. Let's see whether Kent cares about inclusion into TB 45.x. [Approval Request Comment] Regression caused by (bug #): Has always been wrong. User impact if declined: Message created via Windows |Send to > Mail recipient| forcefully downgraded to plain-text potentially losing user-added formatting. Testing completed (on c-c, etc.): Manual. Risk to taking this patch (and alternatives if risky): Low, only well understood faulty code was removed.

Aurora (TB 52): https://hg.mozilla.org/releases/comm-aurora/rev/80372c2c2cabd58e498818e5e6908d3ad4fe6bfe

Beta (TB 51): https://hg.mozilla.org/releases/comm-beta/rev/635203afc5f1a8cbbbc33091bb7111adac17615e

Comment on attachment 8821180 [details] [diff] [review] Patch V.2.1: Don't set forcePlainText=true when MAPI passes plaintext body - removed comment While this is not a particularly risky patch, we are so close to TB 52 beta that I don't think we should be taking non-critical issues that are not regressions.

Note that the fix here was wrong and had to be backed out. Proper fix in bug 1366196.