Cannot open HTML-Emails in Browser #94

Description

By right-clicking on attachments, it is possible to open them in an external program. Currently, this is not possible with the HTML part of HTML-Emails. The reason is that attachments are only saved to a temporary file that can be opened if they are displayed in the header of the email.

Here is the relevant chain:
'KMReaderWin::renderAttachments(partNode * node, const TQColor &bgColor )' calls 'partNode::attachmentDisplayInfo() const' and checks if the attachment should be displayed in the header of the email.
If the file should be displayed in the email header, the file gets written with 'KMReaderWin::writeMessagePartToTempFile( KMMessagePart* aMsgPart, int aPartNum )'. This part is skipped with the HTML part of the email.

If you force 'displayInHeader' to true, the HTML file gets written, and it is possible to open it. To fix this issue 'KMReaderWin::renderAttachments' should check if the node is a HTML part and call 'KMReaderWin::writeMessagePartToTempFile'.
And 'KMReaderWin::writeMessagePartToTempFile' should write the file with an .html extension, or else the file will be saved as 'unnamed' and the browser opens the file as a text file.

Steps to reproduce

Open a HTML-Email
Right-click on the HTML-Attachment
Click "Open" or "Open in"
HTML-File will not open

In my rough unterstanding, if there is Content-Type that is html, it would make sense to generate a filename with a .html extension. And the filename should be safe regarding two aspects:

should not be able to use the suggested filename to do funky things, like go elsewhere in the filesystem.
it should not collide with other filenames.

I wonder if we also need an extra dialog to ask if we really want to open the file. The problem is that a htm file can have active contents and will call home when loading additional sections like images.

I am not a contributor, so I am unable to create a Pull Request. The attachment includes a patch that fixes this issue.

First, it writes all files to a temporary file, regardless of whether they are displayed in the header of the mail.
Second, it checks while writing the temp files if the file is an HTML file and adds a file extension. This is necessary as the HTML part of an email has no name and gets saved as unnamed. The browser will then open the file as text and not as an HTML file.

I don't know if there are any major drawbacks of writing all files. If necessary, we could limit this to HTML files only.

@MicheleC Any opinions?

fix_open_html.txt

1.5 KiB

I am not a contributor, so I am unable to create a Pull Request.

Here you go, added you to the Contributors group. You should now be able to create a PR following the instructions from here

Haven't looked at the patch yet, will wait for the PR :-)

Fixed by PR #103.