Re: Multipart issues (WAS: Re: Restart F32 WiFi on ThinkPad P72)
On Thu, 2020-05-28 at 12:12 +0100, Patrick O'Callaghan wrote:
On Thu, 2020-05-28 at 13:20 +0930, Tim via users wrote:
> On Wed, 2020-05-27 at 19:55 -0400, Todd Zullinger wrote:
> > I don't know Evolution, but if it's presenting choices for
> > the multipart/alternative part, then that latter text/plain
> > part wouldn't be included as an option.
>
> When you have a mail with multiple parts, there should be some sane
> logic applied to handling it. If you have a multi-part alternative
> section, then you should get to see one of those parts by default,
> ignoring the alternatives. When you have another section tacked on
> that is NOT one of the alternatives, it should always be displayed.
>
>
> plain HTML
> text or text
> message message
>
> &
>
> PGP
> signatures
>
> &
>
> list
> footers
>
> Each of those blocks is a section. Only the first two are an OR
> situation, everything else is an AND. The ORed sections should be
> treated the same whether you're reading a message, or replying to it.
>
> Quite how his Evolution created a blank plain-text session I don't
> know, as I can't see an option for whether, or not, to also create a
> plain text section when you're creating a HTML message.
>
> I have noticed Evolution screw up when deleting parts of messages,
> before. Such as trying to trim out quotes. I'd noticed that if I
> tried to remove a few words, it'd often remove the entire quoted
> message. I'd have to copy the text to somewhere else, edit it, then
> paste it back in again. So it's message editor is a bit wacky, as far
> as I'm concerned.
I'll try to take this up on the Evolution list, which (luckily) I
haven't done yet.
poc
This is what I got from one of the Evolution developers:
Right, this is more likely. Having evolution run from a terminal, there
could be seen some runtime warnings related to WebKit, coming either
from Evolution itself or from a WebKitWebProcess (maybe it's still in
the system journal). That would just show there happened something, but
not necessarily what or why.
The composer (the UI part) asks the editor (on the WebKitWebProcess
side) for the content, once in HTML once in plain text (can be in
opposite order). Failing to get it should result in a stop of the send
operation, if I recall correctly. But it seems it was able to read the
HTML part and failed only with the plain text part.
Checking the message itself, the text/plain part is not completely
empty, it contains CRLF encoded in base64.
The HTML part doesn't look like anything complicated, just the
opposite, pretty simple code, without special characters (unless I
overlooked any).
Obviously only Robert can check if there's anything in his journal to
indicate an Evolution problem.
poc