Open Bug 1087105 Opened 11 years ago Updated 3 years ago

thread pane subject shows "ZZZZZZZZZZZZZZZZZ...." instead of subject "CA+IRD=?"

Categories

(Thunderbird :: Mail Window Front End, defect)

31 Branch
x86_64
Linux
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: eggsperde, Unassigned)

Details

Attachments

(1 file)

Attached image InvalidSubject.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140923175406 Steps to reproduce: Sent an eMail to somebody with the subject: "CA+IRD=?" Actual results: The subject is displayed as "ZZZZZZZZZZZZZ..." in the main window in the sent-folder. Expected results: Show "CA+IRD=?" as subject.
Severity: normal → minor
Which version are you using?
Summary: Subject shows "ZZZZZZZZZZZZZZZZZ...." instead of subject → thread pane subject shows "ZZZZZZZZZZZZZZZZZ...." instead of subject "CA+IRD=?"
31.1.2 on Linux Mint 17 KDE. Thunderbird is from the official Mozilla PPA. I just updated it to 31.2.0, but the behaviour stays the same. This is the source code of the mail, used to take the attached screenshot: Message-ID: <5446FFE1.8090802@posteo.de> Date: Wed, 22 Oct 2014 13:52:49 +1300 From: Frank Lehmann <frank.lehmann@posteo.de> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: eggsperde@posteo.net Subject: RE: CA+IRD=? Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060909050707010706030604" This is a cryptographically signed message in MIME format. --------------ms060909050707010706030604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Testmail --------------ms060909050707010706030604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
This problem persists in Tbird 31.7.0 with any subject field that contains the string =? . It depends (I believe) on the remote UA that sent the message. I am currently in an active thread with =? in the subject, and some messages are displayed correctly and others with a very long sequence of ZZZZZ. Doing some tests with a friend, he also saw the bug but not for every sending UA. Outlook seems to be a problem case. Anyway, Tbird is definitely barfing on =? in some cases. Maybe charset dependent?? A fix would be appreciated, this looks really ugly. (I have a screen shot if anybody wants it.)

Brian,
Do you still see this?

Flags: needinfo?(brian.e.carpenter)

That's a blast from the past... yes, just checked, still bad. I recently upgraded T'bird to 78.10.0 on Windows 10. A message that I received in July 2015 still shows this problem. Just grabbed some screen shots, which I can email if you need them - let me know. I'm guessing some code is interpreting =? as flagging non-ASCII when it shouldn't, and then getting an exception, and then mishandling the exception.

It's certainly subtle and it's possibly due to a defect in the sending user agent, but it still seems like a bug.

Flags: needinfo?(brian.e.carpenter)

I have just noticed that in the raw message that triggers the bug, we have:
Subject: RE: [Supa] [Anima] SUPA-Intent =? ANMA-Intent

but in a message in the same thread that doesn't trigger the bug, we have:
Subject: Re: [Supa] [Anima] =?us-ascii?Q?SUPA-Inten?==?us-ascii?Q?t_=3D=3F?= ANMA-Intent

This pretty much confirms that the problem is in handling the charset encoding. Of course, there isn't any charset encoding but Thunderbird thinks there is when it sees =? - but not everywhere, there must be at least two places where it preps the subject for display, and one of them is wrong.

This looks like a dupe of Bug 1466343 to me.

(In reply to Brian E Carpenter from comment #6)

I have just noticed that in the raw message that triggers the bug, we have:
Subject: RE: [Supa] [Anima] SUPA-Intent =? ANMA-Intent

Works for me with TB78.10

Is it possible that the broken subject is still stored in your database from before?
Please copy the email to another folder. Is the subject displayed correctly now?
(Another possibility would be context menu -> Properties -> General Information -> [Repair Folder] )

TL;DR: The bug must lie in the initial creation of the .msf file and is indeed fixed by Repair Folder. But it's still current.

I've already tried isolating a copy in a separate folder: I see a ZZZZ subject. I also tried saving the message as a .eml file and then opening it with T'bird: no problem, the subject displays correctly. So then I created a new test folder with two copies - one by copying the original message, and one by copying the .eml version. When I open that test folder, the copy of the original shows the ZZZ subject and the copied .eml file shows the correct subject.
Then I diffed the two halves of the test folder. The only difference between the "bad" and the "good" messages is that the bad one starts:

From - Thu Jul 23 23:08:14 2015
X-Account-Key: account3
X-UIDL: GmailId14eba668752e1aac
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Delivered-To: brian.e.carpenter@gmail.com

but the good one starts:

From - Tue May 04 08:29:59 2021
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
X-Account-Key: account3
X-UIDL: GmailId14eba668752e1aac
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Delivered-To: brian.e.carpenter@gmail.com

Here's the kicker. To repeat: I see the bug in a brand new folder with a brand new .msf file. But indeed, if I then "repair" the folder, the bug disappears. So, I captured the .msf file before and after the "repair", including:

Before repair:

<(86=11)(87=5b)(88=John Strassner <John.sc.Strassner@huawei.com>)(89
=Brian E Carpenter <brian.e.carpenter@gmail.com>, Laurent Ciavaglia <Laure
nt.Ciavaglia@alcatel-lucent.com>, anima <anima@ietf.org>, "supa@ietf.org" <sup
a@ietf.org>)(8A
=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ$7F)

After repair:

<(8B=11)(8C=5b)(8D=John Strassner <John.sc.Strassner@huawei.com>)(8E
=Brian E Carpenter <brian.e.carpenter@gmail.com>, Laurent Ciavaglia <Laure
nt.Ciavaglia@alcatel-lucent.com>, anima <anima@ietf.org>, "supa@ietf.org" <sup
a@ietf.org>)(9D=[Supa] [Anima] SUPA-Intent =? ANMA-Intent)

So even in a folder created with 78.10.0, the initial .msf file can exhibit the bug but Repair fixes it. There must be a difference between the two code paths (.msf file creation and Repair). I grok Python but I really don't have time to study the code...

Brian
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: