1658155 - HTML/plain text option does not work as expected

Status: NEW

(Thunderbird :: Preferences, defect)

Description

[bege10]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Messages are composed as HTML messages.
Sending options: If recipient cannot accept HTML messages: Send as plain text.
None of the contacts in address book has HTML or plain text option, all are set to unknown.
No entry in list of plain text domains

Actual results:

All recipients get plain text messages.

Expected results:

All recipients should get HTML messages

Comment 1

[bege10]

Attachment: Screenshot_244.png

Comment 2

[Magnus Melin [:mkmelin]]

If the message can be losslessly converted to plain text, the message will be sent as plain text. This is per design.

Comment 3

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #2)

If the message can be losslessly converted to plain text, the message will be sent as plain text. This is per design.

Hmm, no. This is not reporter's case. As seen from screenshot attachment 9169001 [details], Send messages as plaintext if possible is not checked. This is about the poor wording, incomplete UI and illogical behaviour of the following send option:
When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML:
Convert the message to plaintext

Reporter is confused by this:

• all recipients are set Prefers to receive messages formatted as: *Unknown* in address book
• but Thunderbirds just treats them as prefers-plaintext, and performs silent lossy conversion of the message without any need.

Apparently, in 2020, users deliberately composing in HTML expect Thunderbird to send HTML-formatted messages to their pref-unknown contacts, as all modern email systems can handle that.

Comment 4

[Thomas D. (:thomas8)]

That said, bege10, any particular reason why you want to set "Convert the message to plaintext" instead of "HTML-only" or "Plain & HTML" (I'm using shorter wording here)?

The truth is, these options have been misleading, disfunctional and self-defeating for a long time, and the only cure is not to use them until Thunderbird developers will rip them out.

Comment 5

[Thomas D. (:thomas8)]

.

Comment 6

[bege10]

(In reply to Magnus Melin [:mkmelin] from comment #2)

If the message can be losslessly converted to plain text, the message will be sent as plain text. This is per design.

I tested with messages with bold and italic text and the messages were sent in plain text with / and *

Comment 7

[bege10]

(In reply to Thomas D. from comment #4)

That said, bege10, any particular reason why you want to set "Convert the message to plaintext" instead of "HTML-only" or "Plain & HTML" (I'm using shorter wording here)?

I had e-mail lists in the address book that must receive only plain text messages. I want to be sure not to fill up such an e-mail list with HTML or plain and HTML messages if I will write to one some time. Then I would set the option in the address book to "plain text only".

The truth is, these options have been misleading, disfunctional and self-defeating for a long time, and the only cure is not to use them until Thunderbird developers will rip them out.

As described this function is necessary and should not be ripped out but fixed.

Comment 8

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. from comment #3)

Apparently, in 2020, users deliberately composing in HTML expect Thunderbird to send HTML-formatted messages to their pref-unknown contacts, as all modern email systems can handle that.

OK, then they should select the "Send HTML anyway" option, no?

Comment 9

[bege10]

(In reply to Jorg K (CEST = GMT+2) from comment #8)

(In reply to Thomas D. from comment #3)

Apparently, in 2020, users deliberately composing in HTML expect Thunderbird to send HTML-formatted messages to their pref-unknown contacts, as all modern email systems can handle that.

OK, then they should select the "Send HTML anyway" option, no?

That is simply not what the preference window says. The wording is clear and makes sense. Only TB does not do what the preference is set to.
If I compose a HTML message and this preference says "pain-text", TB should send it as HTML, of course, unless the address book or the domain list says plain-text only.
The preference does not say "if unknown or plain-text". And that makes sense since I do not want to set every contact to HTML since this is standard nowadays as Thomas D. states correctly.

Comment 10

[Thomas D. (:thomas8)]

(In reply to Jorg K (CEST = GMT+2) from comment #8)

(In reply to Thomas D. from comment #3)

Apparently, in 2020, users deliberately composing in HTML expect Thunderbird to send HTML-formatted messages to their pref-unknown contacts, as all modern email systems can handle that.

OK, then they should select the "Send HTML anyway" option, no?

Yeah, sort of. Only that our pref wording is so grossly misleading that reporter has no way of knowing that this would work for his case.
Bege10, you can actually set "Send HTML anyway" or "Send the message in both plain text and HTML", and when you write only to prefers-plain recipients, it will auto-downgrade to plain without asking.

Here's the details:

https://searchfox.org/comm-central/rev/b3767e49a6acf1f66abd0a276bd71579eada4787/mailnews/compose/src/nsMsgCompose.cpp#4879-4976
https://searchfox.org/comm-central/rev/b3767e49a6acf1f66abd0a276bd71579eada4787/mail/locales/en-US/messenger/preferences/sendoptions.ftl#14

default-html-format-label =
When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML:
Beim Senden von Nachrichten im HTML-Format an Empfänger, die laut Liste HTML nicht empfangen können oder wollen:

• English wording has a subtle twist, trying to say: "if any recipient is not explicitly listed/marked as prefers-HTML" - but that's all but impossible to understand correctly even for the average English user.
• German wording lost that subtle sense completely, clearly translates to "if any recipient is not explicitly marked as plaintext".
• The code doesn't honor either wording, and does something different:

Recipient-prefers scopes and their send format outcomes in code:
all-x means: all recipients prefer x
some-x means: some, but not all recipients prefer x

• all-plain --> plain (silent dataloss downgrade w/o confirmation, placeholder bug 180997)
• all-html --> html
• all other scopes (all-unknown, any mixed recipient preferences incl. some-plain) --> use pref

As you can see, whilst pref looks like user-controlled conflict resolution for some-plain or all-plain, it's de facto used as default send format pref (hence default-html-format-label), because pref defines default format for all scopes involving prefers-unknown, which is contact default setting. The only reasonable choices for default format are: HTML-only, or HTML+plain. It's messy, pandora's box. My attempt to disentangle conflict resolution from default format was wontfixed (Bug 1222176 Comment 85, Bug 1222176 Comment 91).

So I'm not sure if there's anything which we can do here. Maybe to make the wording match reality?

Or maybe this, as a bandaid fix (improve algorithm & UX without adding pref or UI)?

• some-plain|all-plain --> auto-ask if not losslessly convertible (some/all recipients want plain, but msg has HTML - send plain|html|both?)
  • never allow silent dataloss after sending; force user to decide for edge case of prefers-plain
  • only (lossless conversion or plaintext) to all-plain will obviously go through w/o asking.
• AND: be honest about de-facto purpose of pref by rebranding and reducing pref options (because silent downconvert and ask-always are both impossible for unknown, as this bug shows):
  • Default send format for prefers-unknown: html | both

Comment 11

[bege10]

(In reply to Thomas D. from comment #10)

(In reply to Jorg K (CEST = GMT+2) from comment #8)

OK, then they should select the "Send HTML anyway" option, no?

Yeah, sort of. Only that our pref wording is so grossly misleading that reporter has no way of knowing that this would work for his case.
Bege10, you can actually set "Send HTML anyway" or "Send the message in both plain text and HTML", and when you write only to prefers-plain recipients, it will auto-downgrade to plain without asking.

Thank you very much for that clarification! That is an amazingly simple workaround for my issue. The preference is rather a standard preference than a conflict resolution as you explain.

So I'm not sure if there's anything which we can do here. Maybe to make the wording match reality?

This definitely should be an instant fix...

Or maybe this, as a bandaid fix (improve algorithm & UX without adding pref or UI)?

• some-plain|all-plain --> auto-ask if not losslessly convertible (some/all recipients want plain, but msg has HTML - send plain|html|both?)
  • never allow silent dataloss after sending; force user to decide for edge case of prefers-plain
  • only (lossless conversion or plaintext) to all-plain will obviously go through w/o asking.
• AND: be honest about de-facto purpose of pref by rebranding and reducing pref options (because silent downconvert and ask-always are both impossible for unknown, as this bug shows):
  • Default send format for prefers-unknown: html | both

...and this as soon as possible.
Thanks again!

Comment 12

[bege10]

This issue is not solved in TB 91 and as discussed there are two steps to fix and improve it.
Step one could and should be taken immediately:

1. Change German translation that says the opposite of the English wording. Currently the English wording reflects the behavior of this preference.
2. Change the behavior of this preference as discussed (to what now the "wrong" German translation says).