User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060530 Minefield/3.0a1 Build Identifier: Thunderbird version 18.104.22.168 (20060308) I have my e-mail account set to "Compose messages in HTML format", but I often want to send plain ASCII messages. When I tell Thunderbird Options > Format > Plain Text Only, the text does not convert to fixed width, I still see bold, and hyperlinks, I don't get 72-column wordwrap, etc. Reproducible: Always Steps to Reproduce: 1. Set Tools > Account Settings > Composition and Addressing > "Compose messages in HTML format" 2. Reply to a complicated message, or create a new message. 3. Choose Options > Format > Plain Text Only from the menu. 4. Write stuff, paste HTML into it, etc. Actual Results: The Format menu and toolbar vanish, but the font for new text is still Serif variable width, existing text and pasted text is still formatted as HTML, I can still press Ctrl-B to get bold text, etc. If I save and reopen the message in Drafts, it's still not plain text. If I View Source of the saved message in Drafts, its still an HTML message. It's as if Options > Format > Plain Text Only does nothing to the message, but is just a flag telling TB to convert the message in the future. If I select all and choose Edit > Rewrap, most formatting goes away, but the message is still in proportional Serif. It's only when I Send or Send Later that TB converts the message to plain text (in my Sent or Unsent folder). Expected Results: When I switch to Plain Text Only TB should convert the message to plain text and follow jwz's http://www.jwz.org/doc/html-compose.html guidelines for the plain-text message composition window . I think the message composition behaves correctly if the Account Settings does not have "Compose messages in HTML format" checked. But I need to compose both HTML and plain text messages in one account! The behavior is so broken, and yet I can't find a bug report matching my problem. Perhaps my TB installation is messed up?!
I found and voted for bug 216132, so I think this bug is either a dupe of it, or reports that Options > Format is badly named for what it actually does.
The problem with Options > Send Format is that "Send" is ambiguous; users might interpret it as an action verb that delivers the message like File > Send Now. Maybe Options > Message Delivery Format > ... Or Options > Set Send Format > ... if space is tight.
> interpret it as an action verb that delivers the message like File > Send Now. I think considering it's a submenu with radios, it should look safe enough even with just "Send Format". "Send/Sending/Delivery Format" all sound reasonably fine to me. (fi: "Muotoilu" -> "Muotoilu lähetettäessä" tjsp imo, fwiw).
Bwinton, what do you think about this?
There's no chance we'll be able to fix the underlying bug, and show in the compose window the actual plain-text message that we will be sending? "Delivery Format" would be similar to "Delivery Status Notification" earlier in the menu, and different from "Send Now"/"Send Later" in the File menu (both of which use "Send" as an action), so if we need to change the menu, "Delivery Format" would be my preference.
If the underlying bug is bug 216132, then that one is far in the future. Let's make the label better till then.
Created attachment 676275 [details] [diff] [review] patch I can confirm that when the format is toggled in the menu, the HTML formatting bar does hide when not needed (the plain text option is chosen), but the existing formatting is not removed in the msg body.
Comment on attachment 676275 [details] [diff] [review] patch Review of attachment 676275 [details] [diff] [review]: ----------------------------------------------------------------- Delivery Format is ok with me. r=mkmelin ::: mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd @@ +139,5 @@ > <!ENTITY returnReceiptMenu.accesskey "t"> > <!ENTITY dsnMenu.label "Delivery Status Notification"> > <!ENTITY dsnMenu.accesskey "N"> > +<!ENTITY deliveryFormatMenu.label "Delivery Format"> > +<!ENTITY deliveryFormatMenu.accesskey "f"> Should be F, asscesskeys are case sensitive (but both cases "work"...)
Created attachment 678052 [details] [diff] [review] patch v2
Comment on attachment 678052 [details] [diff] [review] patch v2 I like it. ui-r=me!