274156 - Attachment icon displayed for multipart/mixed with just one part (body)

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Björn Lindahl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I've received two mails from the same sender with the same subject. I.e. the
both messages was replied from the same "base" message I sent so the subject is
the same. The second mail have an attachment but not the first. In the inbox
both messages have a symbol (in the "sort by attachment" column) indicating that
they have an attachment. 

If I select the message or open it no attachment is shown so it seems to be only
in inbox window there is something wrong.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Cowperthwaite]

Select the message which has an attachment icon but no apparent attachment.
In the menu, select   View | Message Source

In the window, look down the list of headers for one beginning with
  Content-Type:
What is that header?

Comment 2

[Björn Lindahl]

(In reply to comment #1)
> Select the message which has an attachment icon but no apparent attachment.
> In the menu, select   View | Message Source
> 
> In the window, look down the list of headers for one beginning with
>   Content-Type:
> What is that header?

Here is the content:

Content-type: multipart/mixed; boundary="Boundary_(ID_xiHpxm8gdao2o6S0uY4V5Q)"
X-Virus-Scanned: by amavisd-new at mai.liu.se
X-Spam-Checker-Version: SpamAssassin 2.64-liu_20041015_1656 (2004-01-11) on
avalon.unit.liu.se
X-Spam-Level:
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no
version=2.64-liu_20041015_1656
References: <[e-mail]>
X-Authentication-warning: water.mai.liu.se: pgand owned process doing -bs
Original-recipient: rfc822;[e-mail]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--Boundary_(ID_xiHpxm8gdao2o6S0uY4V5Q)
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT

Comment 3

[Mike Cowperthwaite]

Well, multipart/mixed implies that there is an attachment, so the icon is being 
displayed correctly.

If you scroll down in the message source, you'll the various parts -- each of 
them will (or should) also have its own Content-Type.  You've already shown the 
Content-Type of the first part (the message body) which is text/plain.  Are 
there any further parts below?

Another question: does the icon (in the thread pane) continue to display once 
the message has been loaded?

Incidentally, which version of TB are you using?  I'm assuming 1.0; if you're 
running with something older, you definitely should update because there has 
been a recent change with how this icon is handled.

Comment 4

[Björn Lindahl]

(In reply to comment #3)
> If you scroll down in the message source, you'll the various parts -- each of 
> them will (or should) also have its own Content-Type.  You've already shown the 
> Content-Type of the first part (the message body) which is text/plain.  Are 
> there any further parts below?

No, not for the mail with no attachment. If I look at the source for the mail
actually containing an attachment there are Content-Type for the attachment
itself as you mention. It looks like this:

--Boundary_(ID_s22lL+tbXbpw7gh7amp/Zg)
Content-id: <[e-mail]>
Content-type: APPLICATION/PDF; name=FSTAMS07.pdf
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename=FSTAMS07.pdf
Content-description:

To summarize, the mail that is indicated to contain an attachment but actually
don't contain one have two Content-Type entries

Content-type: multipart/mixed;
in header

Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
before message body



And the mail that really have an attachment contain these three Content-Type
entries:
Content-type: multipart/mixed; boundary="Boundary_(ID_s22lL+tbXbpw7gh7amp/Zg)"
in header 

Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
before mesage body

Content-type: APPLICATION/PDF; name=FSTAMS07.pdf
below message body, before the attachment



> Another question: does the icon (in the thread pane) continue to display once 
> the message has been loaded?

Yes. 

Also, if I open the mail, I don't see any attachment field in the mail. I mean,
in the mail that actually have an attachment the pdf-file attached is displayed.
In the other mail no attachment-field (I guess it could have shown an empty
attachment-field or something). 


> Incidentally, which version of TB are you using?  I'm assuming 1.0; if you're 
> running with something older, you definitely should update because there has 
> been a recent change with how this icon is handled.

Yes, I'm running TB 1.0.

Comment 5

[Mike Cowperthwaite]

The subject is invalidly encoded -- it's declared in Base64, which requires that 
the encoded string be an even multiple of 4 bytes; this string is 34 bytes, the 
two '=' signs at the end (before the terminating "?=") are superfluous.

The dupe has a discussion on whether Mozilla should or should not allow 
superfluous padding.

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

Comment 6

[Mike Cowperthwaite]

Sorry, I'm an idiot -- that comment was posted into the wrong bug.

Comment 7

[Mike Cowperthwaite]

OK, I can reproduce this.  Since we hide attachment icons when there is a vCard 
attachment, I think we should be able to hide the attachment icons where there 
is *no* attachment.

Reproduced with TB 1.0, Win2K.  Probably belongs in All/All.

Comment 8

[David :Bienvenu]

I have a fix for this - I'm just testing it out.

Comment 9

[David :Bienvenu]

Attachment: proposed fix

basically, always set the attachment flag when finished downloading a message,
in case it was set incorrectly by the header parsing code.

Comment 10

[Scott MacGregor]

Comment on attachment 169392 [details] [diff] [review]
proposed fix

can you check this into the branch too David?

Comment 11

[David :Bienvenu]

fixed on trunk and aviary 1.0 branch (post 1.0)

Comment 12

[Alan Dobkin]

I think this patch/fix may have caused another bug in recent nightlies
preventing attachments from being displayed in some configurations (maybe
specific to IMAP?).  Please refer to the following post:

http://forums.mozillazine.org/viewtopic.php?t=201776

Can someone please confirm this problem and reopen this bug if necessary?

Thanks,
Alan

Comment 13

[Mike Cowperthwaite]

(In reply to comment #12)
> I think this patch/fix may have caused another bug in recent nightlies
> preventing attachments from being displayed in some configurations (maybe
> specific to IMAP?).  Please refer to the following post:
> 
> http://forums.mozillazine.org/viewtopic.php?t=201776
> 
> Can someone please confirm this problem and reopen this bug if necessary?

Hmmm... I wonder if that's the same as bug 278595.

Comment 14

[Alan Dobkin]

Apparently, this is not an IMAP vs. POP issue, and I don't think it is the same
as bug 278595 based on that bug's description.  However, I think I have found
the problem.  Apparently, it is caused by the Enigmail extension in combination
with the patch checked in on 12/22/2004 in this bug.  There are two workarounds
I have tested to remedy this problem, but it really needs to be fixed in the
current code (either in Thunderbird or Enigmail or both):

1)  Disable the Enigmail extension.  It does not have to be uninstalled;
disabling it alone works fine.

2)  Revert to the a nightly build or release prior to 12/23/2004.

Alan