[Users] Question regarding forward of HTML e-mails
freebsd at grem.de
Sun Aug 12 17:40:32 CEST 2012
On Sun, 12 Aug 2012 12:12:59 +0200
Colin Leroy <colin at colino.net> wrote:
> On 11 August 2012 at 22h49, Michael Gmelin wrote:
> > I'm not certain what's the best way to resolve this situation -
> > there are two issues here:
> > - Change this, so it works correctly on an immediate forward (so
> > make sure autosave doesn't mess with it)
> > - Make sure that it also works if somebody reopens a previously
> > saved draft (in the end, as a user I expect this to work if I
> > interrupt writing an email and continue writing it later)
> Fixed (by making sure text/* attachments Disposition-Type are set to
> attachment, regardless of the edit mode).
I applied that fix manually to my source tree and I can confirm that it
works as expected. I was wondering if that's a little bit too
pragmatic, but I can't think of a real world use case where somebody
has multiple text attachments that should be shown inline (and if so,
that's usually a MUA feature at the receiving end and most of the time
not even what users want - just remembering how Apple Mail is inlining
source code sometimes in a way that makes it impossible to save), so I
guess that's safe.
> > In addition to this problem, I also noticed that the configuration
> > option "Select the HTML part of multipart/alternative messages"
> > doesn't work as expected (using the fancy plugin), since it not only
> > opens the HTML part of multipart/alternative, but also
> > multipart/mixed emails, even if the HTML part is a named attachment.
> Fixed too.
I tested this, but it's not working as expcted.
I checked the fix in CVS (3.8.1cvs30) and I think there is a typo in there - in
line 1472 of messageview.c it says:
mimeinfo->disposition == DISPOSITIONTYPE_ATTACHMENT
IMHO this should be !=, so it reads:
mimeinfo->disposition != DISPOSITIONTYPE_ATTACHMENT
Also, after testing the change I realized, that this is still showing
the HTML part of multipart/mixed (whereas the setting says it will only
So I would suggest to also check if alt_parent->subtype ==
"alternative". (The changes after line 1495 are fine, the comparison
operator is ok and since it is only executed in the context of a
multipart/alternative header anyway).
The following patch fixes the issue for me. Since I don't know
claws inside out and I can't tell if there might be any negative side
effects, but I'm relatively certain that this is sane:
--- src/messageview.c.orig 2012-08-12 17:30:39.005347683 +0200
+++ src/messageview.c 2012-08-12 17:30:55.725296727 +0200
@@ -1469,7 +1469,8 @@
} else if (mimeinfo->type == MIMETYPE_TEXT &&
!strcasecmp(mimeinfo->subtype, "html") &&
- mimeinfo->disposition == DISPOSITIONTYPE_ATTACHMENT &&
+ mimeinfo->disposition != DISPOSITIONTYPE_ATTACHMENT &&
+ !strcasecmp(alt_parent->subtype, "alternative") &&
mimeview_select_mimepart_icon(messageview->mimeview, mimeinfo); goto done;
I attached a patch which preserves tabs (I replaced tabs inline for
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 590 bytes
Desc: not available
More information about the Users