850199 - wrong encoding while forwarding an email if the last attachment is a non UTF-8 plaintext attachment

Status: RESOLVED DUPLICATE of bug 1026989

(Thunderbird :: Message Compose Window, defect)

Description

[David]

Attachment: wrong encoding (last attachment is ANSI).eml

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120826082904

Steps to reproduce:

- Compose a new email (in UTF-8 for example) and make sure to add some accentuated chars
- Attach any non UTF-8 text file encoded in ANSI for example (like ISO-8859-1)
- Try to forward (inline) this email...


Actual results:

- The body of the mail is wrong encoded as if TB used the encoding of the last attachment to decode the body. Every accentuated chars are wrong.


Expected results:

- Whatever charset is used for plaintext attachments, it should not impact the body of the email.

Comment 1

[David]

Attachment: good encoding (last attachment is utf8)

Comment 4

[WADA:World Anti-bad-Duping Agency]

Root cause of "charset is pcked up from last attachment" was resolved by bug 1026989 at last.

Some valuable bug reports from users were hidden/lost/ignored by "duping to bug 716983, then duping bug 716983 to other bug".
Unfortunately, or fotunately, only "garbled display in Forward Inline case" was resolved by unknown bug while the other bug was being processed, so nothing was resolved by the other bug.

Duping this bug to bug 1026989, for ease of tracking, search, understanding current status of problem.

Comment 5

[WADA:World Anti-bad-Duping Agency]

FYI.
Patch of bug 1026989, one liner patch, was proposed in the other bug to which bug 716983(and bug 701818 too) had been duped to. The patch was dig out from the other bug by bug 1026989, and long lived "charset is picked up from last attachment" issue has been resolved by bug 1026989.

Why such "digging out hidden important patch from the other bug" should be needed in B.M.O?