Received an email that is in HTML and had a PDF attached. I pressed reply, and it took a while to create the reply window that eventually contained the original text plus a whole load of garbage which i assume is a dump of the PDF attachment Reproducible: Always Steps to Reproduce: 1. Reply to html email with PDF attached (make sure "Prefer HTML to plain text" is NOT set 2. 3. Actual Results: creates a reply window containing the original text plus a whole load of garbage which i assume is a dump of the PDF attachment Expected Results: Create a reply window only containing the original text
Got the same with a PNG attached. Current workaround: mark the text you are replying to and then reply -> will only copy out the text of the reply.
closing account so closing bugs
Erm... no? This is still a bug and you closing your account does not make the bug disappear. I'll just rereport the same thing. :-S
What I am saying is: please reopen; thanks!
Can confirm this. Kmail 16.08.1 on Opensuse Tumbleweed.
Can confirm this bug with png attachments as well as the workaround from comment 1, on Kmail 5.3.0, latest packages from opensuse Tumbleweed. This is a rather annoying bug in everyday use of kmail. I'm happy to test/provide more details if this is helpful. It seems that it doesn't recognize the mime type of the attachment. It simply quotes the binary content of the attachment, and produces many lines as e.g.: > ÷$÷É_]±ÓN"2Î<ðDÀ?Âwr:½®*Tá©Äoù¶ü|_
Created attachment 101760 [details] Example mbox showing problem. I'm also seeing this, specifically for HTML only emails (ie. no text/plain part in the mail) with embedded images. The attached file is a simple email that shows the problem with a multipart/related - On hitting reply the quoted text is 'Image1' which is the data for the first attached image, not the expected 'HTML Text'.
Created attachment 101783 [details] Code hack After some more digging around, I discovered that toplevelTextNode() in utils.cpp is returning non-text parts. That is because AttachmentMessagePart extends TextMessagePart, and therefore it's been deeming images/etc. as textual. The attached patch hacks a quick fix to not return an AttachmentMessagePart which seems to work around the problem and makes replies work as expected for me.
Can reproduce with 16.08
*** Bug 369245 has been marked as a duplicate of this bug. ***
*** Bug 368692 has been marked as a duplicate of this bug. ***
Git commit bf247fc9e802a39b60c8828019401569f6ad99fa by Sandro Knauß. Committed on 26/10/2016 at 15:41. Pushed by knauss into branch 'Applications/16.08'. Fix: Attachments are included as plain text in replied mails Thanks to Simon Levitt to point to the corrent part that needs to be fixed. FIXED-IN: 5.3.4 M +2 -1 mimetreeparser/src/bodyformatter/utils.cpp http://commits.kde.org/messagelib/bf247fc9e802a39b60c8828019401569f6ad99fa
Is my 'hack', really the correct fix? Why are AttachmentMessagePart objects deemed textual?, that seems wrong to me.
Hmm, it seems fine to not include text attachments either, but there seems to something else broken, as a rar attachment (see Bug 369245) is definitely no text.
The current class hierarchy has nothing to do with representation of a specific "mime"-type. And in this hierarchy AttachmentPart is a subclass of TextPart, because AttachmentPart has every property of a TextPart. That's why isTextPart is true for every attachment.