By default every time I send a message I get a dialog box that asks me if I want to send as plain text/html/both. Instead of having a dialog box it might be better to have 3 tabs similar to Composers Normal/HTML Tags/Source/Preview tabs. Plain Text/Formatted Text/Both That way, there is visual feedback, there is no more need for another annoying dialog box, and if you paste something into the email which includes HTML you can see what it will look like when it sends as plain text before you actually send it.

*** Bug 275968 has been marked as a duplicate of this bug. ***

*** Bug 284568 has been marked as a duplicate of this bug. ***

Three tabs doesn't really make sense in this context. How would the Both tab be displayed, in any meaningful way, that would be different from the other two tabs? You can't actually display "both" at once; and a switch on the Both tab to switch the view would be just as easy as switching back and forth between the HTML and Plain tabs. So assume a two-tab model. The main drawback to having a tab is the expectation that the plain-text one would be an active editor. Altho this sounds good, editing in the plain text window while maintaining formatting consistency in the HTML view would be a complex problem that I doubt would be worth the effort. The Plain tab *could* be read-only, but we'd be forever Wontfix'ing requests to make it active. Instead of a tab, there could be a preview popup (as mentioned in bug 39854). Alternately, there could be a switch (as bug 140800); but again, the problem of switching *back* to HTML and getting the formatting right, remains. A popup could have a widget to select the Send format -- the same flag as set by the Options | Format menu item (and which would similarly override the need for the dialog). You could also have a button on the "How do you want to send this?" dialog which would open the popup. > there is no more need for another annoying dialog box Avoiding the dialog is a different question. The whole point of the dialog is that you, as the sender, may not have considered that some of your recipients may be restricted to plain-text clients, meaning they'll be presented with HTML source. The easiest, and "correct," way to override this is to create an address-book entry for each recipient explicitly stating that they "prefer" HTML. This process could be made easier; see bug 246757, bug 162554.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

This seems to be related or somewhat orthogonal to bug 140800.

Given the massive complexity and doubtful feasibility of implementation as hinted in comment 3, I don't see this as a confirmed feature request.

I agree with Thomas. Also see his comment in bug 275968 comment #5. Let's get the bug off our books after 13 years.