Closed
Bug 174396
Opened 22 years ago
Closed 22 years ago
message with embedded image send as plaintext generate bogus content
Categories
(MailNews Core :: MIME, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.3alpha
People
(Reporter: moz-bugzilla2, Assigned: bugzilla)
References
Details
(Keywords: dataloss, Whiteboard: MS Outlook)
Attachments
(3 files)
195.46 KB,
message/rfc822
|
Details | |
994 bytes,
text/plain
|
Details | |
1.02 KB,
patch
|
cavin
:
review+
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
Steps to reproduce 1) Send message from Outlook with a graphic attached to it Mozilla email account 2) Message displays fine in Mozilla 3) Reply to that message in Plain Text Only format 4) Mozilla and Outlook user see the reply message that just says "This is a multi-part message in MIME format." Expected Result Message looks correct in Outlook and Mozilla. If the attachment is not a graphic, it works fine or if you send message in Rich Text Format. Content of message that causes problems replying to: Received: by myserver.com id <01C273AF.C22D60A0@myserver.com>; Mon, 14 Oct 2002 14:30:23 -0400 Message-ID: <51CE20E519524040B1E012A0C4B3012C0CB3FC@myserver.com> From: Steve Wardell <steve@myserver.com> To: Steve Wardell <steve@myserver.com> Subject: test 2 Date: Mon, 14 Oct 2002 14:30:23 -0400 MIME-Version: 1.0 Content-Type: image/jpeg; name="Sprint Conferencing Final.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Sprint Conferencing Final.jpg" /9j/4AAQSkZJRgABAQEAAAAAAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAgACADASIA AhEBAxEB/8QAGQAAAgMBAAAAAAAAAAAAAAAABwgBAgYF/8QAJRABAAEEAQQCAwEBAAAAAAAAAQID BAURBgAHEiEUMRMiQSMy/8QAGgEAAQUBAAAAAAAAAAAAAAAABAABAgMFBv/EACURAAECBQMEAwAA AAAAAAAAAAECAwAEBREhEhMxIiNRYUGBkf/aAAwDAQACEQMRAD8AanoWd4u50OL0qmIwc4Vc/Uj+ 89Eo2UU2SkPpqJ7jF9BqUvWic8g5/XqXN7QxOXxlvbvlTo1iVlVnH1rziyvYj7/Y8oH8EffQgq8O xlWrUq1uSTq1akmc6lStj5SnJdspLfbVVVfavWfMzStOloZ8x2NEoTG6HagoBIzpzk+DjgfPmDV2 p7i0OT2tKxyNUjlInjCctHyNCohoKgCoASBlENThTI/SrY7jGPx91GvbcjYzijoq2BvSJ7L4REER EQREEL/FeRcizUoWdlkcfdSowjGveStLesQfF1OpGjfKeTF/5iG/oAdSlplSgEuDMD1qisMuKdlH Bt85uLeuM+orcdrL38FT4vcbnEbjxfxyrX0J0yWvTKMacWUd62Eoqf0++gjyTK81wGWucflM1mra 8t9NSmZCrKLFUjUpyX96UtOpfYjGQSE6brrN834ZiuY2dvRysatOtbT86F1QSNWlvXnEURjINSii Pp1uMUsmJYOJsnBgSkVxySfCn+tB5Bz+XhXsDmuc8kzdDDYHOZqvf1vat/VIUYGvKpOW3xibNun7 AGUoxk1/EsTXwfHbHHXmTusrc0IJUvLqSzqyVV9qgLoFUAFU28jttwTG8Ewnw7H/AHva2pXl7OOp 3EzevW3xgbfGO3W1VlKUpa3pSsvsp6jcw1crAqT3bSEtjgAAfZj/2Q==
Assignee | ||
Comment 1•22 years ago
|
||
Reporter, the sample message you provide does not match your description of the pronlem! Can you either attach to this bug report a full sample message or send me one. Thanks
Whiteboard: MS Outlook
Reporter | ||
Comment 2•22 years ago
|
||
Reporter | ||
Comment 3•22 years ago
|
||
Reporter | ||
Comment 4•22 years ago
|
||
Take a look at those two attachments and see if that clears things up.
Assignee | ||
Updated•22 years ago
|
Attachment #105237 -
Attachment mime type: message/rfc822 → text/plain
Assignee | ||
Comment 5•22 years ago
|
||
I am using a Win2K debug trunk build from last night and I can reply to the test message (in HTML) and view the replied message without problem.
Reporter | ||
Comment 6•22 years ago
|
||
Try with text and not HTML and that's when the problem will occur.
Reporter | ||
Comment 7•22 years ago
|
||
This is becoming a real nuisance. This problem is very easily reproducable. Mozilla's not even able to read the replies I send out sometimes.
Assignee | ||
Comment 8•22 years ago
|
||
Ok, I can reproduce this problem with the following easy step: 1) Open an HTML message compose 2) type some text and insert an image (directly in the message body, not as attachment) 3) go to menu Options/Format and select Plain Text only 4) Send the message ==> the message body contains only: This is a multi-part message in MIME format The whole message body is missing!
Status: NEW → ASSIGNED
Summary: Replies to Exchange MIME messages display multi-part message error → message with embedded image send as plaintext generate bogus content
Target Milestone: --- → mozilla1.3alpha
Assignee | ||
Comment 9•22 years ago
|
||
We were adding the Multipart blurb when we detected we have attachment. But in the case where we send the message in plain text, we drop related attachment. The test wasn't catching that case which cause the message body to be replaced by the blurb. The solution is to not check anymore on the attachment count but rather on the type of the main part.
Assignee | ||
Updated•22 years ago
|
Attachment #106841 -
Flags: review?(cavin)
Comment 10•22 years ago
|
||
Comment on attachment 106841 [details] [diff] [review] Proposed fix, v1 r=cavin.
Attachment #106841 -
Flags: review?(cavin) → review+
Comment 11•22 years ago
|
||
Comment on attachment 106841 [details] [diff] [review] Proposed fix, v1 why don't we need to check m_attachment_count > 0 anymore?
Comment 12•22 years ago
|
||
Comment on attachment 106841 [details] [diff] [review] Proposed fix, v1 1) // Does the top part is a multipart container? probably should be: // Is the top part a multipart container? 2) can you add a comment to the code about why we don't have to check m_attachment_count anymore? once you do that, sr=sspitzer
Attachment #106841 -
Flags: superreview+
Assignee | ||
Comment 13•22 years ago
|
||
I don't check m_attachment_count anymore because it's not reliable. The goal here is (and was) to add the blurb text to the top part if it'a multipart. Therefore instead of testing some other variable, why not simply test the type of the top part, this is 100% reliable. Adding a comment would not be helpfullm esppecially once the code is changed!
Comment 14•22 years ago
|
||
1) "I don't check m_attachment_count anymore because it's not reliable." are there other places in the code we are using it, and it's not reliable? (looking in nsMsgSend.cpp, there might be more.) 2) "Adding a comment would not be helpfullm esppecially once the code is changed!" I think it would be worth adding a comment like: // can't use m_attachment_count because it's not reliable // instead use type of main part // see bug #174396 comments are free (except when checking out the source over CVS). Code gets moved around, white space changes, etc, which makes it hard to follow with cvsblame. a comment just makes people think twice (and check existing bugs) before changing (or reverting) code. does your fix regress http://bugzilla.mozilla.org/show_bug.cgi?id=160029?
Assignee | ||
Comment 15•22 years ago
|
||
1) m_attachment_count is nor reliable to determine if we are sending a multipart message. m_attachment_count contains the real number of attachment we have processed but not the number of attachment we will really send. That why it's much better to test the to part's type. 2) ok, I'll add the comment
Assignee | ||
Comment 16•22 years ago
|
||
Fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 17•22 years ago
|
||
Woho! Works great. 2002112004 on W2K seems to have no problems now. Now my workmates will stop telling me they can't read my messages :)
Status: RESOLVED → VERIFIED
Comment 18•22 years ago
|
||
*** Bug 178099 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
*** Bug 187238 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
*** Bug 187474 has been marked as a duplicate of this bug. ***
Comment 21•22 years ago
|
||
*** Bug 188428 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
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
•