Using shared-mime-info 1.6 on my system (Arch Linux - https://www.archlinux.org/packages/extra/x86_64/shared-mime-info/) results in a majority of emails rendering blank pages when viewing in html. Downgrading to shared-mime-info 1.5 resolves the issue completely with all emails displaying properly. I've not yet discovered a correlation between the emails that display correctly and the ones that result in blank screens. I will report back if I am able to do so. Additionally, here is a link to the forum thread with others experiencing the same issue: https://bbs.archlinux.org/viewtopic.php?id=211484 Thank You.
Using share-mime-info 1.6 on a fedora system and every html mail displays fine with the Fancy plugin. Looks like some other problem on arch.
Bryan, you probably should look in the direction of webkit, which is what the Fancy plugin uses, rather than Claws Mail.
Thanks for the pointer and for taking the time to look at the issue!
*** Bug 3649 has been marked as a duplicate of this bug. ***
I understand that this is closed, but people come here looking for answers to this and I just found one, so I figure it is worth documenting what I found to try and help others... :-) When using the Fancy plugin files like this are created: ~/.claws-mail/mimetmp/000000c0.mimetmp.html Note the ".html" extension. By bisecting my configuration, I found I had a file called: ~/.local/share/mime/packages/user-extension-html.xml containing: <?xml version="1.0" encoding="UTF-8"?> <mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> <mime-type type="application/x-extension-html"> <comment>html document</comment> <glob pattern="*.html"/> </mime-type> </mime-info> This looks like it maps files with extension .html to MIME type application/x-extension-html. Removing this file and running: update-mime-database ~/.local/share/mime stopped the problem with the Fancy plugin occurring. Note that running the above command makes other changes to ~/.local/share/mime/ so you might want to backup this directory when testing. If I re-add the file and run the above command again the problem returns. Another thing that works around the problem is removing the changes to /usr/share/mime/packages/freedesktop.org.xml mentioned at https://bbs.archlinux.org/viewtopic.php?pid=1623743#p1623743, which seems to explain why downgrading shared-mime-info helps. I'm not sure what created ~/.local/share/mime/packages/user-extension-html.xml. However, neither it nor most of the other contents of ~/.local/share/mime/ had changed for over a year (probably since I installed this new laptop and started using it). However, when I upgraded shared-mime-info to 1.6 back in early May, this triggered a bug somewhere in combination with the existence of this file. I wish I understood more...
*** Bug 3713 has been marked as a duplicate of this bug. ***
*** Bug 3776 has been marked as a duplicate of this bug. ***
So the solution would be either: not to use the ".html" extension, use an appropriate extension or to force the mimetype onto the plugin. Of the three files in my ~/.claws-mail/mimetmp/, two are xhtml and the other is rough html with no DTD.
No. According to the arch bug item the solution is to remove ~/.local/share/mime/packages/user-extension-html.xml and then run update-mime-database ~/.local/share/mime
Yep, Fiddling with mime types does indeed nullify the effect of this bug. This is achieved at the expense of another (unknown) program which is now broken in some way. Furthermore, under certain circumstances a link in an HTML mail such as: <a href="#top">To the top</a> opens this temporary file in the default (?) browser, rather than the required behaviour of scrolling to the top. A typical user will regard both these behaviours as bugs. Hint: There are no typical users reading this thread.
Oh, This is probably fixed by commit b320c5095cd51213520d8011ae4969e97c8f7436 :)