Unread text mails falsely shown with attachment icon (paperclip), if multipart/mixed

NEW
Unassigned

Status

Thunderbird
Folder and Message Lists
9 years ago
4 months ago

People

(Reporter: Alexander Kriegisch, Unassigned)

Tracking

({testcase})

Trunk
testcase

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: 2.0.0.19 (20081209)

Often I receive e-mails without attachments which are shown with a paperclip symbol, .i.e. as "message with attachment", anyway in the message list pane, until I actually click on and display them. Then Thunderbird notices that there is no attachment at all and the paperclip symbol goes away. I would expect the symbol not to appear at all.

Those messages with false paperclip symbols seem to have in common that they are of MIME Type "multipart/mixed", even though they contain just one part.

BTW, I really searched the database for this error because I believe somebody else must have noticed it before. Unfortunately I found no corresponding ticket. So if this is a duplicate, please flag it accordingly. Thanks.

Reproducible: Always

Steps to Reproduce:
Receive incoming e-mail without attachments, but of type multipart/mixed, which looks like this in source code:

From - Tue Feb 17 15:14:25 2009
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <foo@bar.de>
X-Original-To: foo@bar.de
Delivered-To: blah@bar.de
Message-Id: <0000000.mmailer000000000@fritz.box>
From: "Sender" <baz@bar.de>
To: <foo@bar.de>,
Date: Tue, 17 Feb 2009 10:48:42 +0100
Subject: My subject
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------=_Boundary._0000000.mmailer.fritz.box0000000000"
X-KasLoop: blahblah

This is a multi-part message in MIME format.

--------=_Boundary._0000000.mmailer.fritz.box0000000000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

QW5ydWYgYW4gZnJlZW5ldA0KDQoxNy4wMi4wOSAxMDo0ODozNw0K

Actual Results:  
Paperclip symbol is displayed which then vanishes after reading the message

Expected Results:  
No paperclip

Comment 1

9 years ago
multipart/mixed usually do have attachments, no? xref bug 241203

Comment 2

9 years ago
That's bug 274156, but was marked fixed. Has this been reverted somewhere?
(Reporter)

Comment 3

9 years ago
@Magnus: No, bug 241203 describes the opposite behaviour of icons *not* being displayed even though there is an attachment.

@rsx11m: I have no idea how this was supposed to be fixed. As a matter of fact, the error happens. Obviously during mail download only top level headers are checked, at least this is what I assume, not having looked into the code. Thus,  only the first occurrence of "multipart/mixed" is registered and consequently an attachment icon is displayed. Later during full e-mail parsing (i.e. when the user actually displays the message), Thunderbird notices that the multipart actually only contains one part or maybe two parts (ASCII + HTML), but nor "real" attachment. In this case the icon goes away, now correctly showing the status "no attachment".

My question/wish would be to verify the MIME message structure right during download, so the correct icon is (not) displayed right from the start. Would this slow down Thunderbird or is it feasible?

Comment 4

9 years ago
There have been quite a few changes to msgHdrViewOverlay.js since that patch was checked in (revision 1.41), and my question was actually more for Magnus than yourself. The issue is that on initial examination of the message, only the top-level headers are apparently looked at (which is the normal behavior for IMAP, and there is an option to download headers only for POP accounts).
At this point, it likely isn't known how many MIME parts are actually in the message. Thus, the full message would need to be parsed already (or the body structure requested in the IMAP case) when new mail is received.
(Reporter)

Comment 5

9 years ago
So it is exactly like I assumed. So maybe we need a case distinction:
    a) If only top-level headers are downloaded at a certain time, assume that a multipart message has attachments. -> display icon
    b) As soon as the full message or at least the message's full (nested) MIME structure is downloaded, analyse it and update the icon accordingly, i.e. right during download, not just when the message is displayed or marked as read.

Probably it would be a good idea to make (b) configurable via a documented option in the UI or at least via an about:config toggle. The default for full parsing during download can be "off", if it is expensive CPU-wise, otherwise I would be happy with the default "on", too. As long as I can activate this feature in any sensible way I will be content.

Comment 6

9 years ago
(In reply to comment #2)
> That's bug 274156, but was marked fixed. Has this been reverted somewhere?

Don't know, but indeed that bug looks very similar...
(Reporter)

Comment 7

9 years ago
I just noticed something else: The problem is not restricted to inbound messages. Whenever I send a plain text message with an automatic VCF attachment - a feature provided by Thunderbird itself - messages in the "Sent" folder are displayed with paperclip symbols until I actually open and read them. Usually I do not do that with outbound messages, but I have to do it in order to make the paparclip go away. A sample message is structured like this:

...
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
...
Content-Type: multipart/mixed;
 boundary="------------030704030402030207060104"

This is a multi-part message in MIME format.
--------------030704030402030207060104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

...

--------------030704030402030207060104
Content-Type: text/x-vcard; charset=utf-8;
 name="MyCard.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="MyCard.vcf"

...
--------------030704030402030207060104--

Comment 8

9 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090525 Lightning/1.0pre Shredder/3.0b3pre

This annoying behavior is present in Thunderbird 3 beta.
Aurimas (or reporter) can attach here a complete mail sample?

Comment 10

8 years ago
Created attachment 404198 [details]
Shows attachment when it is unread

Updated

8 years ago
Keywords: testcase

Comment 11

8 years ago
I know this regressed since tb2 (i think at least going back to last spring). Don't think we actually have a bug open for it, so confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

Comment 12

8 years ago
I highly doubt this regressed - we've always treated multipart/mixed as having attachment until we find out differently.

Comment 13

8 years ago
You're right.
Keywords: regression

Comment 14

8 years ago
I see this on Mac, not Win-specific as per the bug report. Also, it has always been the case as long as I remember. With regard to Comment 12, not sure why it takes a click on the message to "find out differently"? (but then again I'm not a programmer :-)  )

It is more than an annoyance to not be able to distinguish multi-part msgs from true attachments when reviewing newly received mail. It looks like 1/2 the people who write to me (many of my friends and colleagues use Apple Mail which only does plain or multi-part) have sent me attachments and I must click on every paper-clipped msg in the list to see whether anything is really attached to any of them.

Updated

8 years ago
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Duplicate of this bug: 557469

Comment 16

5 years ago
The bug is still here in TB17.0.3. Some messages get the paperclip icon in the mail list after I do 'Repair folder'. If I select those messages (click on them in the list) - the paperclip icon disappears. Imagine that you have thousands emails marked as "has attachment" so you have to click on each of them just to be sure.

Updated

2 years ago
See Also: → bug 1177080

Comment 17

a year ago
Created attachment 8795240 [details]
Another simple test case: multipart/mixed but there is no attachment.

(In reply to David :Bienvenu from comment #12)
> we've always treated multipart/mixed as
> having attachment until we find out differently.
That appears to be the case still.
You need to log in before you can comment on or make changes to this bug.