Using: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 I wanted to compose new messages in plain text (with the option to switch to HTML) and to reply/forward in whatever format it arrived in. Since that does not appear to be a supported combination of options, I finally acquiesced and set up HTML as my default for everything. Now, I've noticed if I compose a message that doesn't contain any formatting it is sent in plain-text. Turns out there is _another_ setting which controls this tucked away under the compose window's Options menu. So there is at least four different locations which control the format of message composition. But no button to switch plain<->HTML in the compose window. The default settings result in a sort of guessing game which format will be used. My request: consolidate these options somehow or have them cooperate better at least. Relevant locations (& my settings): - Tools > Options > Composition > Send Options > Text Format: Send the message in HTML format anyway - Account settings > Composition & Addressing > [X] Compose messages in HTML format - Write (compose window) > Options > Delivery format: Autodetect - Address book > Per-user format preferences: none specified Select related issues: bug 394725 bug 268012 but 921836

Hi Patrick, thanks for your spot-on analysis of the unfortunate design and behaviour seen in TB24. It's actually worse than you describe, because even explicit and relevant HTML formatting gets ripped out by the misguided and buggy design of "Format > Auto-Detect", as I've demonstrated with extensive screenshots seen on Bug 414299. Unfortunately addressing such problems cooperatively and productively was systematically blocked by a certain strongly pro-plaintext developer who originally wrote much of the respective logic and has uncooperatively defended his code tooth and nails against any changes, improvements, or even discussion. For a full overview of delivery-format related bugs, see delivery-format-ux tracker bug 889315, which I filed and filled exactly starting out from what you say in comment 0: (In reply to Thomas D. from comment #0) > This is a tracker bug for delivery format UX issues (HTML vs. Plaintext), > with special focus on the interaction of {Delivery Format | Auto-Detect} > with other settings and related UX-failures. > > There is a recurrent theme in many bugs that users are reporting problems of > ux-control, ux-consistency, ux-efficiency, ux-wysiwyg, and ux-trust > regarding the delivery format of their compositions, especially involving > unexpected downgrading of HTML compositions to plaintext by Auto-Detect > feature, which is currently the forced default for many everyday scenarios. > The historically-grown interactions between the various settings and > behaviours are highly complex and not transparent to the extent of being > practically unpredictable. The good news being, I think TB 31 has started to sort out some of the mess wrt the per-contact settings on AB cards, to err in favor of HTML which is certainly more appropriate these days: Bug 970118. As for the missing switch between plaintext and HTML, that's an age-old design failure (Bug 140800) which isn't easy to fix and I guess we're lacking the manpower to address that, also in view of many other important bugs (and perhaps it's less of an issue these days because imo people will usually either use HTML or plaintext, but rarely both in a systematic way).

(In reply to Patrick O'Keeffe from comment #0) > So there is at least four different locations which control the format of > message composition. But no button to switch plain<->HTML in the compose > window. The default settings result in a sort of guessing game which format > will be used. +1 > My request: consolidate these options somehow or have them cooperate better > at least. You're most welcome to provide ideas for consolidation, but I don't expect that to be easy unless we want to remove much of the original functionality. So imo "have them cooperate better" looks like a good approach. IMO, the general directions for this approach should be: - Default bias for HTML (use/downgrade to plaintext only when explicitly activated by user; including in AB: unknown/new recipients = HTML preference). - Strict respect for ux-wysiwyg: If I see any HTML or css formatting in my composition, even just <tt> or <pre>, it must be sent as HTML. So auto-detect (if still needed at all) needs to be tamed. - Explore prioritizing message-centric setting of delivery-format: This needs more detailed analysis, but I suspect we'll be better off with a message-centric approach to these settings: If a message is composed in HTML, it should be sent in HTML (perhaps with an automatical plaintext alternative for recipients explicitly listed as "plaintext"). If it's composed in plaintext, send plaintext. Maybe that boils down to revisiting those options in Tools > Options > Composition > Send Options > Text Format, or taming Auto-Detect again (should auto-detect still be the default?). I suppose it doesn't make sense to compose in HTML and then downgrade that message and send only plaintext, even to a so-called "plaintext" recipient. I suspect recipients who are unable of receiving HTML messages are more or less a thing of the past. But even for those few "plaintext" recipients, sending HTML+plaintext looks like the better/safer thing to do, whereas sending only downgraded plaintext looks like a useless/datalossy thing to do (unless explicitly demanded by user). Perhaps that plaintext recipient can save the HTML part and view in browser. Perhaps the plaintext recipient gets access to an HTML mail reader on another machine. Perhaps he'll lateron upgrade his own mailing application to something capable of HTML. Perhaps we can simplify things here or at least err on the safe side, i.e. preserve the original HTML composition of the user whenever possible (unless explicitly instructed otherwise). > Relevant locations (& my settings): > - Tools > Options > Composition > Send Options > Text Format: Send the > message in HTML format anyway > - Account settings > Composition & Addressing > [X] Compose messages in HTML > format > - Write (compose window) > Options > Delivery format: Autodetect Autodetect is the worst player here, because that's what mostly makes the result unpredictable. > - Address book > Per-user format preferences: none specified

Patrick, until the mess will finally be sorted out (God only knows if or when), this might help you: https://addons.mozilla.org/de/thunderbird/addon/always-html/ For more overview in this matter, pls look at bug 889315 (delivery format ux fail tracker).

(In reply to Patrick O'Keeffe from comment #0) > Now, I've noticed if I compose a message that doesn't contain any formatting it is sent in plain-text. Report for such phenomenon looks closed sometimes as dup of bug 414299 which is about "<tt> and friends". Please watch Bug 1210244. We are looking for simple/easy/minimum solution for such mystery of "mail composed in HTML mode is silently sent as text/plain by Tb, with UNKNOWN reason". > I wanted to compose new messages in plain text (with the option to switch to > HTML) and to reply/forward in whatever format it arrived in. You doesn't look to know Shift+Compose, Shift+Reply, Shift+Foward etc. Shift modifier in Composer == Invoke composer with opposite mode to default composition mode of used Identity. Note: this doesn't work in "Edit Draft or Edit As New Mail of text/plain draft/mail". This is because there is currently no way to edit text/plaain mail as HTML. IIUC, this "Shift modifier" is inherited from Netscape, so it's never new feature. The "Shift modifire in mail composition" worked in some limited functions only in the past, but "Shift modifire in mail composition" was already sorted out, so it recently works in almost all "invoking composer via button/menu". It can be called "Hidden option", because "Help ducument" is not attached to package of Thunderbird, as not attached in Firefox. (in Mozilla/Mozilla App Suite, Help document was attached to package, and it's inherited by SeaMonkey.)

FYI. In SeaMonkey, Compose menu button has next drop down menu. Compose in HTML Compose in Plain Text In Thunderbird, Write menu button has next drop down menu. Message Event Task Following may be convenient for Tb users. In Thunderbird, drop down menu of Write menu button. Message (Plain Text) , or opposite of current Identity setting is shown Message (HTML) , or current Identity setting is shown Event Task IIRC, Shift modifier for mail composition was implemented in Compose(Write) menu button only. So, enhancement and sorting out of "Shift modifier in mail composition" was done for Thunderbird, and "Shift modifier in mail composition" are consistently working in Button, Menu, Context menu, and Compose(Write), Reply, Forward.

(In reply to WADA from comment #5) > Following may be convenient for Tb users. > In Thunderbird, drop down menu of Write menu button. > Message (Plain Text) , or opposite of current Identity setting is shown > Message (HTML) , or current Identity setting is shown > Event > Task I think this can be done, please file it separately and I do it.

(In reply to :aceman from comment #6) > I think this can be done, please file it separately and I do it. I've opened Bug 1213628 for it.