295445 - [Thunderbird] Sending HTML+plain-text (multipart) email message with wrong encoding does not warn

Status: RESOLVED DUPLICATE of bug 302748

(Thunderbird :: Message Compose Window, defect)

Description

[Shai Berger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Thunderbird 1.0.2 (20050317)

This starts like a problem report:

I responded to a mailing-list message which was encoded iso-8859-1. I wrote my
reply in Hebrew, and saw nothing wrong with it, as I usually use HTML, and so it
was edited as HTML. However, the plaintext sent was all question marks. I only
became aware of this when I saw my message coming in from the mailing list.

So, I would like to add this behavior: If a message is sent in both HTML and
plaintext -- most importantly, if it is edited as HTML, and contains characters
in the HTML which cannot be encoded in the plaintext encoding, warn before
sending, and give me a chance to change the encoding (or the message).

Thanks,
Shai.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jungshik Shin]

I'm not sure if we want to do this for plain text + html. We do warn and prompt
a user to specify what to do when a plain text message contains character
outside the repertoire of the selected encoding

Comment 2

[Shai Berger]

(In reply to comment #1)
> I'm not sure if we want to do this for plain text + html. 

What are the cons?

Comment 3

[Simon Montagu :smontagu]

The reason that we have an option of sending in both HTML and plaintext is so
that recipients who can't handle HTML mail can read the message, no? So I would
think we want to ensure that the plaintext is always readable.

Comment 4

[Prognathous]

Confirming bug and changing summary based on the more descriptive Bug 302748
(SeaMonkey/Suite).

I agree with the rational in comment #3, which is why I don't see this as an
enhancement. It's a bug that induces (very minor) dataloss.

Prog.

Comment 5

[Mike Cowperthwaite]

*** This bug has been marked as a duplicate of 302748 ***