Closed
Bug 298596
Opened 19 years ago
Closed 19 years ago
Detaching attachment from complex MIME message rewrites message incorrectly
Categories
(MailNews Core :: Attachments, defect)
MailNews Core
Attachments
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mcow, Assigned: Bienvenu)
Details
(Keywords: fixed1.8)
Attachments
(1 file)
945 bytes,
patch
|
mscott
:
superreview+
mscott
:
approval1.8b5+
|
Details | Diff | Splinter Review |
Spun off from bug 286446. Given a complex message, such as: multipart/related multipart/alternative text/plain text/html application/msword After detaching the attachment, the resulting message includes two copies of the text/html body, one of which is hidden between MIME boundaries (without headers of its own): multipart/related; boundary=XXX --XXX multipart/alternative; boundary=YYY --YYY text/plain OK OK OK OK --YYY text/html <html>OK OK OK OK</html> --YYY-- <html>COPY, DOESN'T BELONG HERE</html> --XXX text/x-moz-deleted blah blah blah --XXX-- Steps to reproduce: 1) integrate attachment 177627 [details] into your mail system 2) View the message; delete and/or detach the Joe.doc att't. 3) View the resulting message's source Actual results: 3) Bogus MIME structure observed Expected results: 3) Correct MIME structure
This bug is holding back my mail archiving. I would like to save attachments without having my mail format butched.
I think this should block SeaMonkey's release because it's a major functionality that is broken and causing bloat.
Flags: blocking-seamonkey1.0b?
Keywords: regression
Comment 4•19 years ago
|
||
If you want this bug fixed in 1.0b, you should nominate it for 1.8b5. The relevant code is shared and 1.0b will be released off of 1.8b5, whatever that is.
See my previous comment for the reason.
Flags: blocking-seamonkey1.0b? → blocking1.8b5?
Comment 6•19 years ago
|
||
David, I'll let you decide what to do with this bug.
Flags: blocking1.8b5? → blocking1.8b5-
Assignee | ||
Comment 7•19 years ago
|
||
I'll try to fix it. Changing this code is risky, however.
Assignee | ||
Comment 8•19 years ago
|
||
don't display cached part when stripping attachments.
Attachment #197455 -
Flags: superreview?(mscott)
Updated•19 years ago
|
Attachment #197455 -
Flags: superreview?(mscott) → superreview+
Reporter | ||
Comment 9•19 years ago
|
||
(In reply to comment #8) > don't display cached part when stripping attachments. ?? Does that fix really belong to this bug?
Assignee | ||
Comment 10•19 years ago
|
||
Comment on attachment 197455 [details] [diff] [review] proposed fix I'll let this bake on the trunk for a little bit, but if everything is ok, I'd like to check it into the branch as well.
Attachment #197455 -
Flags: approval1.8b5?
Assignee | ||
Comment 11•19 years ago
|
||
>> ?? Does that fix really belong to this bug?
yes, it does - it was the call to display the cached part (the multipart
alternative that we've cached for display) that was causing us to write out the
extra copy of the body.
Comment 12•19 years ago
|
||
Please re-ping me when you feel this has baked enough and I'll approve the fix.
Comment 13•19 years ago
|
||
When this bug is worked on, perhaps two more attachment-deletion related errors can be also fixed? 1. When an attachment is deleted from a message where the sender had requested a receipt notification ("Return-receipt-to:" header, probably the same with "Disposion-Notification-to:"), a popup window appears again, asking if the notification shall be sent. This should not happen. 2. After having deleted an attachment, the junk status of the message is set to "unknown". The junk status should not change upon attachment deletion. (Or should a new bug be opened for these?)
Updated•19 years ago
|
Flags: blocking1.8b5- → blocking1.8b5+
Reporter | ||
Comment 14•19 years ago
|
||
I've just tried TB 1.6a1+0928, and this patch appears to have fixed the reported problem. Thanks, David!
Assignee | ||
Comment 15•19 years ago
|
||
great, thx, Mike - pinging mscott for a=, per his request.
Updated•19 years ago
|
Attachment #197455 -
Flags: approval1.8b5? → approval1.8b5+
Assignee | ||
Updated•19 years ago
|
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•