GNOME Bugzilla – Bug 204137
Evolution: Can't read email attachement if the attachment is an email
Last modified: 2005-11-20 01:01:32 UTC
Package: Evolution Priority: Normal Version: 0.10 Synopsis: Evolution: Can't read email attachement if the attachment is an email Bugzilla-Product: Evolution Bugzilla-Component: Mailer Description: In the mail reader, with a mail message that has an attachment which is itself a mail message. The attachement icon has a popup with three choices: Save to disk Open in external viewer view inline 'Save to disk' works. 'View inline' works, but there is no way to turn it off other than changing the selection in the message list window. However 'open in external viewer' cannot be selected. If this is because no external viewer has been configured, then where is the viewer configured? Meta question: Where is the functioning of the handling of attachements specified in a coplete and definitive form that can be verified against compliance?
This works for me. Is the attached message signed or encrypted? If it's not sensitive please attach it to this bug. As for the meta-question, mail-format.c contains this code. It's hard to get more specific.
Created attachment 39980 [details] THis does not show the 'paperclip' icon in the message list
Created attachment 39981 [details] Saved under linux/evolution. Thas attachements but shows no paperclip
1. I get the paper clip. I believe a bug related to this was fixed recently so you might want to try using the latest round of snapshots 2. (Technical notes) The reason that the attachment popup menu widget disappears is because mail-display.c:inline_cb and button_press toggle the disposition of the attachment from "attachment" to "inline" and queue a redisplay. The display is rebuilt and the mail code, seeing that the attached message is inline, displays it that way without the popup widget. Solutions... I'm not fond of how mail-display.c just changes the disposition of the attachment. Maybe create a hashtable or perform a gtk_object_set_data that stores a boolean "expanded" state; initialize it from the attachment disposition, but then toggle that. Then we can use the disposition and the "expanded" state to determine whether to add the attachment header or not.
The part of this that is still a bug is basically 1587. *** This bug has been marked as a duplicate of 201587 ***