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)
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
Comment 1•19 years ago
|
||
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.
Comment 2•19 years ago
|
||
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.
has header entry - Content-Type: multipart/mixed; will show up with attachment, but has no.
has header entry - Content-Type: multipart/mixed; will show up with attachment, but has no.
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.
Comment 8•19 years ago
|
||
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.
| Reporter | ||
Comment 10•19 years ago
|
||
| Reporter | ||
Comment 11•19 years ago
|
||
Comment 12•19 years ago
|
||
the fix I talked about to clear the attachment icon is only in trunk tb and seamonkey builds, afaik.
| Reporter | ||
Comment 13•19 years ago
|
||
> 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?
| Reporter | ||
Comment 14•18 years ago
|
||
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.
Comment 15•17 years ago
|
||
(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?
Comment 16•17 years ago
|
||
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.
Description
•