Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Replying to email from a plain text domain, the composer uses the default composer for the identity

  • 4 replies
  • 3 have this problem
  • 1 view
  • Last reply by gild

more options

Email from - say - example.com is always sent in plain text. I therefore want to communicate with people @example.com in plain text. So I added example.com to the list of plain text domains via Tools -> Options -> Composition -> Send options -> Plain text domains.

When I reply to email from example.com, the reply uses the HTML composer, which is the default for the identity that the email was sent to (and therefore that the reply will come from.)

That seems like a silly design choice.

Is this the expected behavior? If not, is there a bug tracking this?

Is there a config setting I can change or an extension I can install that will cause the plain text composer to be used for replies to plain text domains?

I'm using the 2015-07-22 nightly, though I think this behavior goes way back.

Thanks.

P.S. I know that I can click Shift+Reply to use the composer that is the inverse of the default for the identity. It would be nice to not need to do that, because inevitably I forget, and so the process becomes: Click Reply. Notice that it's using the wrong composer. Close message. Command+Click or Control+click Reply. Realize that's not the right way to do it. Close message. Click Shift+Reply. Finally.

Email from - say - example.com is always sent in plain text. I therefore want to communicate with people @example.com in plain text. So I added example.com to the list of plain text domains via Tools -> Options -> Composition -> Send options -> Plain text domains. When I reply to email from example.com, the reply uses the HTML composer, which is the default for the identity that the email was sent to (and therefore that the reply will come from.) That seems like a silly design choice. Is this the expected behavior? If not, is there a bug tracking this? Is there a config setting I can change or an extension I can install that will cause the plain text composer to be used for replies to plain text domains? I'm using the 2015-07-22 nightly, though I think this behavior goes way back. Thanks. P.S. I know that I can click Shift+Reply to use the composer that is the inverse of the default for the identity. It would be nice to not need to do that, because inevitably I forget, and so the process becomes: Click Reply. Notice that it's using the wrong composer. Close message. Command+Click or Control+click Reply. Realize that's not the right way to do it. Close message. Click Shift+Reply. Finally.

Modified by IshmaelYavitz

All Replies (4)

more options

Would it be a problem to uncheck the 'Compose messages in HTML format' box in the 'Manage Identities...' page for that identity? You would then be composing in plain text for All messages for that identity, unless you manually switch composers.

Or, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.

Here are some articles that may help -

http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29 https://support.mozilla.org/en-US/kb/using-identities

more options

gild said

Would it be a problem to uncheck the 'Compose messages in HTML format' box in the 'Manage Identities...' page for that identity? You would then be composing in plain text for All messages for that identity, unless you manually switch composers.

Yes. example.com is the only plain text domain, so doing that would result in more work.

gild said

Or, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.

Interesting suggestion.

I'm going to continue to maintain that Thunderbird's current behavior is at worst a bug, and at best a concession to novice users ("Why when I'm replying to email does it sometimes use the HTML composer and sometimes use the text composer?!?!") that should be overridable via a config setting that, in effect, communicates, "Yes, I understand that by putting domains in the plain text domain list it means that I'll be shown the text composer."

My understanding is that since Mozilla hung Thunderbird out to dry, there is no longer any paid staff working on it?

Do any TB developers or team members read this forum? If not, I'll just open a bug on bugzilla rather than waiting to see if anyone knows of an existing bug number...

Thanks,

Ish

more options

IshmaelYavitz said

gild said
Or, create a new identity for plain text only messages, You can set it up with the same email address, but with slightly different settings. Then select that identity when you compose a plain text message and the composer should change accordingly.

Interesting suggestion.

So, I just tested this (though using identities with different default mail formats) and it doesn't work that way. Switching between identities with different default formats (text/HTML) doesn't change the composer.

Modified by IshmaelYavitz

more options

Looks like a bug in TB. Even in safe mode, identities do not work as they used to. In the past, I could change HTML/text mode, signatures, and even change SMTP servers. Now, except for the identity name on new writes, everything seems to be locked into the Main Account Settings.