Re: [Evolution] .p7m attachment freezes Evolution


yes, you are perfectly right. It is indeed like that.
'evolution --disable-preview' does not seem to help, and I get the following

(evolution:19884): camel-WARNING **: 23:34:43.409: Truncated UTF-8 buffer (The
cause might be missing character encoding information in the message header. Try
a different character encoding.)
(evolution:23667): evolution-util-WARNING **: 11:31:36.250: Failed to call a
DBus Proxy method org.gnome.Evolution.WebExtension::AddCSSRuleIntoStyleSheet:
Timeout was reached

Is there another  workaround? I see I may download the message as a .mbox file.
May I recover the attached .pdf.p7m file from there? 

Thanks, Cheers

On Tue, 2020-01-21 at 18:44 +0100, Milan Crha via evolution-list wrote:
On Tue, 2020-01-21 at 18:11 +0100, mario chiari wrote:
I tried cseveral time, and sometimes, after some time, Evolution
shows the underlying code of the file  (I may save it as a .mbox

I guess, and only guess, that the .pdf.p7m is shown in its source form,
like a plain text message, and as it's quite large (several megabytes?)
then preprocessing of the data and WebKitGTK+ rendering takes a long
time. You can work with the application, only the preview panel is
frozen and doesn't update, right? You may also see that one of
WebKitWebProcess processes is using a lot of CPU. There is already
filled a bug about this [1].

From my point of view, in your specific case, I'd say the problem is on
the sender's side, sending large PDF file incorrectly attached into the
message. I admit I didn't see the message itself, whose structure can
prove that I'm wrong.

A workaround is to disable the preview (Ctrl+M), or by running
evolution as 'evolution --disable-preview', and then do something with
the message. Eventually wait until the rendering is finished and only
then do something with the message. How long it'll take depends on the
message size.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]