Closed Bug 302864 Opened 19 years ago Closed 17 years ago

multipart/mixed messages have attachment icon, but parts are 'inline'

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: metoo_b1, Unassigned)

Details

Attachments

(6 files)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.8b4) Gecko/20050721 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.8b4) Gecko/20050721 SeaMonkey/1.0a

Seamonkey displays mail folder entries as "with attachment" icon,
but there are no real attachments, only HTML or other bodies.
Happens when mail header contains either:

Content-Type: multipart/mixed;
Content-Type: multipart/alternative; 

To test, the .msf file needs to be deleted, normal refresh
of the msf file sometimes does not show the faulty behaviour.

Seems to be similiar to this bug in Thunderbird:
https://bugzilla.mozilla.org/show_bug.cgi?id=269273


Reproducible: Always

Steps to Reproduce:
Any mail containing 
Content-Type: multipart/mixed;    or
Content-Type: multipart/alternative; 
but without real file attachment, like:

Content-Type: multipart/alternative;
This is a multi-part message in MIME format.
--------------64171C924A6B
Content-Type: text/HTML
text text

other:

Content-Type: multipart/mixed;
boundary="----=_Part_1_26219575.1118010303235"
------=_Part_1_26219575.1118010303235
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline 
text text

Actual Results:  
Attachment icon appears on mail entry and on attachment flag column.


Expected Results:  
show not attachment icon
Please provide a full message -- the initial headers of the message are 
insufficient to diagnose this report.  Save the message as a .EML file and 
attach to this bug using the Create New Attachment link above.
we show an attachment icon for multi-part mixed messages based purely on the
content type. Does the icon still display after you read the message? If that
was the case, that might be a problem. But if the attachments are displayed in
the attachment area, then we'd still display the icon.
Attached file mbox folder, 1 mail β€”
has header entry -  Content-Type: multipart/mixed;
will show up with attachment, but has no.
Attached file mbox folder, one email β€”
has header entry -  Content-Type: multipart/mixed;
will show up with attachment, but has no.
Attached file mbox folder, one mail β€”
has header entry -  Content-Type: multipart/mixed;
will show up with attachment, but has no.
this is an exception, on recent seamonkey builds,
it had an attachment icon, on build 20050731 is has none.
(In reply to comment #2)
> we show an attachment icon for multi-part mixed messages based purely on the
> content type. Does the icon still display after you read the message? If that
> was the case, that might be a problem. But if the attachments are displayed in
> the attachment area, then we'd still display the icon.

Yes, the mails have no attachment window, only an icon for attachment.
Samples are from Mozilla 1.7.8, where they do not show "with attachment".

Note: there might be a conflict with the new option to remove 
attachments from mails. I have no clue how Seamonkey identifies
real attachments or removed attachments.

More info: the recent Seamonkey builds act differently on Content-Type:
 multipart/mixed;,        is always shown as "with attachment" icon
 multipart/alternative;   some builds do not show the "with attachment" icon
To test, always delete the MSF file.
The attachment from comment 5 is *not* multipart/mixed, it's 
multipart/alternative.

(In reply to comment #7)
> More info: the recent Seamonkey builds act differently on Content-Type:
>  multipart/mixed;,        is always shown as "with attachment" icon

Those attachments correctly hide the attachment icon once the message 
has been opened, which is what David is talking about in comment 2.  Showing 
an icon for those messages before they've been opened is by design and 
unlikely to be changed.

>  multipart/alternative;   some builds do not show the "with attachment" icon
> To test, always delete the MSF file.

If you can point to a specific build (Seamonkey or TB) where attachment 191236 [details] 
shows an icon initially, that's a bug.  Claiming the problem is in "some builds" 
is too vague, and sounds to me like you misidentified the problem in the first 
place.  TB 1.0+0725 does not show an attachment icon for that message.
Attached image attachment indicator column β€”
Attached image attachment icon β€”
Attached image attachment icon preview pane β€”
the fix I talked about to clear the attachment icon is only in trunk tb and
seamonkey builds, afaik.
> The attachment from comment 5 is *not* multipart/mixed, it's 
> multipart/alternative.

correct, sorry, typo. 

> Those attachments correctly hide the attachment icon once the message 
> has been opened, which is what David is talking about in comment 2.  Showing 
> an icon for those messages before they've been opened is by design and 
> unlikely to be changed.

Attachment icon does not hide after opening. Retestet on Win98 
and Win XP Pro using SeaMonkey 20050721 and 20050731, see screenshots.

Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.8b4) Gecko/20050731 SeaMonkey/1.0a
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8b4) Gecko/20050721
SeaMonkey/1.0a 

> the fix I talked about to clear the attachment icon is only in trunk tb and
> seamonkey builds, afaik.

I used 1.8b4 2005073111 (seamonkey.exe properties)
Please can you point me to the FTP site which has the 
build for seamonkey you refer to?

Version: unspecified → Trunk
Seamonkey 1.1 still has this behaviour. 
When clicking once on such a mail removes the attachment flag.
Seems the .msf refreshing is different between Mozilla (no problem here)
and Seamonkey 1.1.
(In reply to comment #14)
> Seamonkey 1.1 still has this behaviour. 

Maybe; but Sm 1.1 is not Trunk. Is anyone seeing this bug on Sm 2.0a1pre?
No reply to comment #15 after 3 weeks. Comment #14 was over a year ago. Resolving INCOMPLETE.

If you want to REOPEN, please paste the user-agent string (as shown after "Build Identifier:" on the bottom line of the about: page) of a recent build exhibiting the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: