After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 680537 - Reply to individual message in digest generates empty body
Reply to individual message in digest generates empty body
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.6.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[formatter]
Depends on:
Blocks:
 
 
Reported: 2012-07-24 16:06 UTC by Milan Crha
Modified: 2013-09-13 01:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed fixed (2.43 KB, patch)
2012-07-30 15:37 UTC, Dan Vrátil
rejected Details | Review
proposed evo patch (925 bytes, patch)
2012-09-12 16:37 UTC, Milan Crha
committed Details | Review
evo patch ][ (4.80 KB, patch)
2013-01-23 19:05 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2012-07-24 16:06:45 UTC
Have a message digest, which contains various sub-messages (like as attachments). On each attachment button I can select "Reply to sender", "Reply to all".... I selected "Reply to sender" and I get basically empty body, no text is quoted (I have Reply:Quoted in Preferences).

I can reproduce this even with message which has as attachment other message(s).
Comment 1 Dan Vrátil 2012-07-30 15:37:47 UTC
Created attachment 219904 [details] [review]
Proposed fixed

Essentially when we extract content of the CamelMimePart that represents the attachment, we get a CamelMimeMessage. So far OK, but despite the fact, that the message has header "Content-Type: multipart/mixed" or text/plain or whatever, camel_mime_part_get_content_type() always returns message/rfc822 which totally confuses the formatter (and me). This patch simply forces camel_mime_part_get_content_type() to return content type according to what's in the Content-Type header instead of message/rfc822...

This is not an ideal solution, but after several hours of locating and trying to understand the issue I'm really opened to any other solutions....
Comment 2 Milan Crha 2012-07-31 15:58:35 UTC
You should work on a 'content' of the message/rfc822, rather than on message itself. I see [1] it's done this way on reply on root message.

[1] diff --git a/mail/em-utils.c b/mail/em-utils.c
index 3bfeaff..737da06 100644
--- a/mail/em-utils.c
+++ b/mail/em-utils.c
@@ -1267,6 +1267,15 @@ em_utils_message_to_html (CamelSession *session,
 	mem = camel_stream_mem_new ();
 	camel_stream_mem_set_byte_array (CAMEL_STREAM_MEM (mem), buf);
 
+	{
+		CamelDataWrapper *dw;
+		printf ("%s: message is:'%s'\n", __FUNCTION__, camel_content_type_format (camel_mime_part_get_content_type (CAMEL_MIME_PART (message))));
+		dw = camel_medium_get_content (CAMEL_MEDIUM (message));
+		printf ("%s: content is %s, '%s' mime-message:%d mime-part:%d multipart:%d\n", __FUNCTION__, G_OBJECT_TYPE_NAME (dw), camel_content_type_format (camel_data_wrapper_get_mime_type_field (dw)),
+			CAMEL_IS_MIME_MESSAGE (dw), CAMEL_IS_MIME_PART (dw), CAMEL_IS_MULTIPART (dw));
+		
+	}
+
 	formatter = e_mail_formatter_quote_new (credits, flags);
 	e_mail_formatter_set_style (formatter,
 		gtk_widget_get_style (GTK_WIDGET (window)),
Comment 3 Milan Crha 2012-09-12 14:49:03 UTC
Kind of found it. The mail_formatter_quote_run() skips each rfc822, and as the message from digest is parsed as shown below, then it is skipped, and body is left empty.
EMailParser finished with EMailPartList:
	id: .message | cid: (null) | mime_type: (null) | is_hidden: 0 |
          is_attachment: 0
	id: .message.headers | cid: (null) | mime_type:
          application/vnd.evolution.headers | is_hidden: 0 | is_attachment: 0
	id: .message.attachment-bar | cid: (null) | mime_type:
          application/vnd.evolution.widget.attachment-bar | is_hidden: 0 |
          is_attachment: 0
	id: .message.rfc822 | cid: (null) | mime_type: message/rfc822 |
          is_hidden: 0 | is_attachment: 0
	id: .message.rfc822.headers | cid: (null) | mime_type: 
          application/vnd.evolution.headers | is_hidden: 0 | is_attachment: 0
	id: .message.rfc822.attachment-bar | cid: (null) | mime_type:
          application/vnd.evolution.widget.attachment-bar | is_hidden: 0 |
          is_attachment: 0
	id: .message.rfc822.text-highlight.plain_text.0 | cid: (null) | 
          mime_type: text/plain | is_hidden: 0 | is_attachment: 0
	id: .message.rfc822.end | cid: (null) | mime_type: (null) |
          is_hidden: 1 | is_attachment: 0

It seems to me that the issue will be with the way how message/digest is parsed into attachments, because application/mbox attachments do not suffer of this.
Comment 4 Milan Crha 2012-09-12 16:37:26 UTC
Created attachment 224131 [details] [review]
proposed evo patch

for evolution;

After quite some investigation I ended with similar fix as you did, only on a different place and, I guess, in a less destructive way, as I do not modify the message, I only "parse_as" the inner content type.
Comment 5 Dan Vrátil 2012-09-12 17:02:58 UTC
Review of attachment 224131 [details] [review]:

Didn't test, but looks OK. Please commit.
Comment 6 Milan Crha 2012-09-12 17:06:05 UTC
Created commit 409b4a5 in evo master (3.5.92+)
Comment 7 Milan Crha 2013-01-23 19:00:44 UTC
As reported in a downstream bug [1], the fix is not enough, it seems to be more tricky. I suspect the mime parser setting incorrect mime types, the CamelMimeMessage mime type usually matches the one in its content, but not with multipart/digest.
Comment 8 Milan Crha 2013-01-23 19:01:00 UTC
[1] https://bugzilla.redhat.com/show_bug.cgi?id=475117
Comment 9 Milan Crha 2013-01-23 19:05:46 UTC
Created attachment 234236 [details] [review]
evo patch ][

for evolution;

Re-fix, a different approach, which involves only EMailAttachmentHandler. Simple reconstruction of the inner message fixes the issue with different mime types. I'm not brave enough to dive into the mime parser, even, maybe, it does it right, the part is a message/rfc822 after all.
Comment 10 Milan Crha 2013-01-23 19:07:40 UTC
Created commit bf250a0 in evo master (3.7.5+)
Created commit 9f5d682 in evo gnome-3-6 (3.6.4+)