GNOME Bugzilla – Bug 680537
Reply to individual message in digest generates empty body
Last modified: 2013-09-13 01:08:00 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).
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....
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)),
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.
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.
Review of attachment 224131 [details] [review]: Didn't test, but looks OK. Please commit.
Created commit 409b4a5 in evo master (3.5.92+)
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.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=475117
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.
Created commit bf250a0 in evo master (3.7.5+) Created commit 9f5d682 in evo gnome-3-6 (3.6.4+)