Closed Bug 1540943 Opened 6 months ago Closed Last month

Broken message body on forwarding a mail including invalid character

Categories

(MailNews Core :: Internationalization, defect)

defect
Not set

Tracking

(thunderbird_esr6069+ fixed, thunderbird_esr6869+ fixed, thunderbird69 fixed, thunderbird70 fixed)

RESOLVED FIXED
Thunderbird 70.0
Tracking Status
thunderbird_esr60 69+ fixed
thunderbird_esr68 69+ fixed
thunderbird69 --- fixed
thunderbird70 --- fixed

People

(Reporter: yuki, Assigned: jorgk)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Attached file sample.eml

Thunderbird cannot forward a message when the message has a quoted-printable encoded body with invalid character.

Steps to reproduce:

  1. Open the attached file "example.eml".
  2. Choose View => Message Body as => Original HTML or Simple HTML.
  3. Then you'll see an email with a message body "�にほんご".
    The first character is invalid, rest four character is a term
    meaning "Japanese" in hiragana.
  4. Click the "Forward" toolbar button.

Actual result:

The editing message has a forwarded body as: "(B$B$K$[$s$4(B"

Expected result:

The editing message has a forwarded body as: "�にほんご"

Environment:

  • Ubuntu 16.04LTS, Thunderbird 60.6.1 (64-bit)
  • Ubuntu 16.04LTS, Daily 68.0a1 (2019-03-31) (64-bit)

The message has a body "=1B(B=1B=24B=24K=24=5B=24s=244=1B=28B", and the part "=1B(B" is an invalid character.

I've tried with Thunderbird 52.9.1, and it works as expected: the forwarded body has the original body "�にほんご" as-is. So this looks a regression.

Attachment #9055045 - Attachment mime type: application/x-extension-eml → text/plain

Sorry, I'm just going through some old bugs since the beginning of 2019. Yes, in a reply you get what's expected, but when forwarding, you get the raw undecoded (ASCII) text.

If that broke between 52 and 60 it's likely due to the switch to encoding_rs in bug 1363281 which happened during the 56 cycle.

Just for the record: Editing the message as new message (Ctrl+E) shows the same behaviour as Forward since it's a similar code path.

Henri, here's the code that changed:
https://hg.mozilla.org/comm-central/rev/f558febc1ead57c76ba5eb5af4443a67680f7fa4#l3.173

We're now doing "without replacement", so it will just fail on illegal input. What did the previous code do?

BTW, in this case it's called from here:
https://searchfox.org/comm-central/rev/eb044a1bc9fca62c103b25e77dfccb9adcf8a9c4/mailnews/mime/src/mimedrft.cpp#1408
and that will just pump out ASCII as we saw.

This fixes the issue. Somehow in the past in TB 52 nsMsgI18NConvertToUnicode() must have been more tolerant and returned replacement characters for bad input.

Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Attachment #9086291 - Flags: review?(hsivonen)

Changing the summary: This has got nothing to do with quoted-printable, or am I missing something?

Keywords: regression
Regressed by: 1363281
Summary: Broken message body on forwarding a mail including invalid quoted-printable character → Broken message body on forwarding a mail including invalid character
Attachment #9086291 - Flags: review?(hsivonen) → review+
Component: Message Compose Window → Internationalization
Product: Thunderbird → MailNews Core
Attachment #9086291 - Flags: approval-comm-esr68?
Attachment #9086291 - Flags: approval-comm-beta+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/aeca286583a8
Use DecodeWithoutBOMHandling() in nsMsgI18NConvertToUnicode() to handle bad characters better. r=hsivonen

Status: ASSIGNED → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 70.0
Attachment #9086291 - Flags: approval-comm-esr60?
Attachment #9086291 - Flags: approval-comm-esr68? → approval-comm-esr68+
Attachment #9086291 - Flags: approval-comm-esr60? → approval-comm-esr60+
You need to log in before you can comment on or make changes to this bug.