User-Agent: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.0.5) Gecko/2008122011 Firefox/3.0.4 (Debian-3.0.5-1) Ubiquity/0.1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 If you receive a message with an attachment, "attach icon" is showed only after click over this message. Please, see image attached in this bug report. Reproducible: Always Steps to Reproduce: 1. Receive a message with an attachment 2 [review]. Don't select it. You can't see the "attach icon" 3. Select it. Now you can see the "attach icon".

I don't know why the word "attachment" in "Steps to reproduce" is linked to a patch. Don't consider it.

Is this an IMAP account? If yes, the information that an attachment is present may be missing when retrieving the header information from the server, thus it wouldn't be possible to present the attachment icon for a new message until you actually open it.

Yes, this is a IMAP account. Regards, Renato S. Yamane

Actually, don't think it matters if it's imap. (Dupe though.)

Well, I found bug 241203 and related discussions in bug 199979, the latter has been duped to the first bug. Those are marked fixed but have a couple of comments added that occasionally the attachment icon is still missing. It may also depend on the "Show an alert" settings as part of the message has to be downloaded when that preview option is active. Yet have to test that.

Just tried that, and I'm still unable to reproduce this. I have switched off syncing and the alert window to avoid downloading of the complete message, send myself multiple e-mails with attachments from a different account, and all of them had the "attachment" icon next to the subject line. So, that's WFM so far. [Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20090216 Shredder/3.0b2pre]

I check in LKML, and all patchs sent from Greg have this problem in Thunderbird 3b2. I attach a message and source from it.

Comment on attachment 362604 [details] Source code of this message attached above > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline; filename="x86-vmi-put-a-missing-paravirt_release_pmd-in-pgd_dtor.patch" I think that's the issue right here. The patch hasn't really been sent as an attachment (not multipart/mixed), but the entire message shows up as an attachment since a content disposition and a filename are given. Thus, if the initial query of the headers returns the top-level content type, which is not multipart for this e-mail, no attachment is assumed at the display before opening. The issue here would be to request content disposition as well (if possible) in order to resolve that ambiguity. On the other hand, one may argue that this isn't a true attachment, no icon should be shown at all then. So, is this confirmable (could reproduce it with this message) or is the behavior intended, or is the message itself invalid to a certain extent?

Can someone edit status of this bug report? I think that it is reproducible as we can see in Comment #11

I wasn't confirming this report since it's not established yet that this actually is a bug. The message has a rather unusual format of having just a single MIME part which is the attachment, thus waiting for a second opinion. The closest I could find is bug 274156, which aimed to remove the attachment icon if just a single MIME part is present, even if multipart/mixed is given at the top level. But then, there is bug 479017 suggesting that fix was reverted.

I think this can be confirmed - regardless of what is decided on whether or not an attachment icon should be shown for this type of message, the point is: it has to be consistent. Either it is displayed or it is not, both when initially presenting the message as unread and then when it is opened. The IMAP log indicates that Content-Type headers are asked for, but not Content-Disposition, which would be conclusive in this case. Confirming as this is a quite special case of message and doesn't seem to be covered by any other bug, even though this may be resolved by a fix for any related attachment-icon problem elsewhere.

(In reply to comment #11) > The patch hasn't really been sent as an attachment (not multipart/mixed), > but the entire message shows up as an attachment > since a content disposition and a filename are given. Phenomenon after download looks for me Bug 182627. If Content-Type: text/plain; name="...patch", I think attachment icon is probably displayed since initial and Bug 182627 will occur on IMAP mail too.

FYI. Bug 479017 is for opposite phenomenon on IMAP mail(attachment icon disappears after load).

Yes, the problem is similar in that the attachment-status display before opening the message versus after it was opened. There is also bug 229075 on treating anything with a file name given in the content disposition as an attachment, which would be relevant here.