(In reply to Jorg K (GMT+2) from comment #4) > We tried to solve this dilemma in bug 1222176, but that finally didn't go ahead. Thomas, does a single text recipient force the message to plain text? Well, sort of. More precisely, if *all* recipients of the message are marked in AB as "prefers-plain" (allPlain scope), TB will do the following: - ignore user's send options (contrary to what the label suggests: "When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML") - force-downgrade the message, i.e. dump all HTML formatting without warning (I thought there's a bug for that, but I can't find it. Closest: bug 180997). Doing the warning might be non-trivial in the current messed-up state of affairs. The current UI labels are misleading and erroneous, just as the underlying logics. Most options are no-op. Bug 1222176 offered a substantial cure of the status quo, but was rejected with a view on removing the recipient-centric logic of Auto-Detect entirely (which sounds like a good idea in the long run, but doesn't help until that's done). For details of what's currently wrong, see bug 1222176 comment 26.
Bug 1580718 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jorg K (GMT+2) from comment #4) > We tried to solve this dilemma in bug 1222176, but that finally didn't go ahead. Thomas, does a single text recipient force the message to plain text? Well, sort of. More precisely, if *all* recipients of the message are marked in AB as "prefers-plain" (allPlain scope), TB will do the following: - ignore user's send options (contrary to what the label suggests: "When sending messages in HTML format and one or more recipients are not listed as being able to receive HTML") - force-downgrade the message *after* sending, i.e. dump all HTML formatting without warning (I thought there's a bug for that, but I can't find it. Closest: bug 180997). Doing the warning might be non-trivial in the current messed-up state of affairs. The current UI labels are misleading and erroneous, just as the underlying logics. Most options are no-op. Bug 1222176 offered a substantial cure of the status quo, but was rejected with a view on removing the recipient-centric logic of Auto-Detect entirely (which sounds like a good idea in the long run, but doesn't help until that's done). For details of what's currently wrong, see bug 1222176 comment 26.