Thanks for a bug report. The WEBKIT_DISABLE_COMPOSITING_MODE=1 is used by default in the evolution 3.22.3, thus you can run it from the UI as before.

What I see is that either the evolution is not passing data into the WebKitWebProcess, or the WebKitWebProcess is somehow stuck, but in that case you might not see the changing "Retrieving message 'xxx'" in the preview panel too.

Could you install debuginfo packages for the evolution-data-server and evolution, only for these two at this time [1], then get a backtrace of the evolution when it gets into such state, to see what it tries to do, please? Having evolution running also from a terminal as such can show some runtime warnings and/or anything related. You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).

[1] To install the packages you can run as root this command:
   # dnf install evolution-data-server-debuginfo evolution-debuginfo \
     --enablerepo=updates-debuginfo

   Eventually replace the 'install' dnf command with 'update', if you have
   any previous debuginfo packages from the two installed. The important is
   to have installed exact package versions of the binary packages and
   the debuginfo packages, otherwise the backtrace will not be useful much.

Ok. Thanks for the instructions.
I installed the debuginfos, I've done a general system upgrade and started evolution from a terminal, with stdout and stderr each redirected to their own .txt file. Gdb is ready to run and now we just have to wait for the problem to manifest itself...

Created attachment 1233840 [details]
gdb output

Created attachment 1233841 [details]
Standard Output of Evolution

Created attachment 1233842 [details]
standard error of evolution

Thanks for the update. The backtrace from comment #3 doesn't show anything obvious. Maybe the only suspicious thing are those threads with WTF::WorkQueue::~WorkQueue(), but I do not know WebKit that much to be able to tell whether that's a problem or not. I only know that the unit tests also kind of "get crazy" after opening many new composers in a row, when it also exhibits quite many such threads there. The composers use its won WebKitWebProcess, which is closed when the last composer is closed (otherwise it's reused between the opened composers). Maybe that has its impact as well.

From the stderr output those "Error sending IPC message" at the end are usually when closing the composer or a preview window, aka a WebKitWebView instance, form my experience and they are harmless. I cannot speak for the other things there though.

As I indicated above, the interesting thing is that the WebKitWebView seems to be alive, it changes its content when moving between messages, due to the changed "Retrieving message xxx" messages, which are also drawn inside it, but when it should show a more complex code, then it fails. It can be fully on the evolution side, not providing the data to the WebKitWebView. I hoped that it would be visible in the backtrace, but there is nothing indicating a stuck parsing/formatting activity, neither any network activity when downloading the selected message from the server.

I noticed you use evolution-rss. Could you try to uninstall it for a day or two, just to try whether it'll make any difference, please? Your settings will not be forgotten by the uninstall.

Thanks Milan,
evolution-rss is installed but actually not in use. Anyway I removed it and we'll see if I can still reproduce in the nex few days.

I have the same issue and I don't have evolution-rss installed. But in my case the message goes away after some seconds if I stop interacting with evolution.

I haven't been able to get a backtrace, but I'm trying.

Created attachment 1235017 [details]
backtrace from gdb attached to evolution

I managed to get a backtrace as requested:

(In reply to Milan Crha from comment #1)
>    $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt

I confirm it still happens without any evolution extensions.

Thanks for the update. I see one difference between Christian's and Davide's backtraces, the Christian's has one thread connecting an IMAPx account, setting it to be online. Otherwise they both look similarly, with more or less WebKitGTK+ threads. Those with WTF::WorkQueue::~WorkQueue() look suspicious to me, but I'm not a WebKitGTK+ expert.

(In reply to Milan Crha from comment #11)
> Thanks for the update. I see one difference between Christian's and Davide's
> backtraces, the Christian's has one thread connecting an IMAPx account,
> setting it to be online. Otherwise they both look similarly, with more or
> less WebKitGTK+ threads. Those with WTF::WorkQueue::~WorkQueue() look
> suspicious to me, but I'm not a WebKitGTK+ expert.

Just to be clear: I was looking at a local message, not one in an IMAPx account.

(In reply to Milan Crha from comment #11)
> Thanks for the update. I see one difference between Christian's and Davide's
> backtraces, the Christian's has one thread connecting an IMAPx account,
> setting it to be online. Otherwise they both look similarly, with more or
> less WebKitGTK+ threads. Those with WTF::WorkQueue::~WorkQueue() look
> suspicious to me, but I'm not a WebKitGTK+ expert.

That must be https://bugs.webkit.org/show_bug.cgi?id=166645 which was coincidentally reported just today, though it's been broken for months.

(In reply to Michael Catanzaro from comment #13) 
> That must be https://bugs.webkit.org/show_bug.cgi?id=166645 which was
> coincidentally reported just today, though it's been broken for months.

Note: *probably* unrelated to why Evolution stops rendering messages.

I think it depends also on the state of the WebKitWebProcess. The Evolution uses always up to two, one for the message preview, another one for the composers. The later changes when all composers are closed. I do not know whether it'll be of any use, but maybe once you get to the odd state again, check what WebKitWebProcess-es are running and get a backtrace of them. Might be like this:

   $ ps ax | grep WebKitWebProcess

which prints the process ID as the first number in the output on the line, then use it to a very similar command as above (replace the PID with it):

   $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt

(I'm sorry, I forgot to add:)

Maybe the evolution itself caused a stuck of the WebKitWebProcess, like when searching for the sender's photo in the address books (if you've it enabled).

(In reply to Milan Crha from comment #16)
> (I'm sorry, I forgot to add:)
> 
> Maybe the evolution itself caused a stuck of the WebKitWebProcess, like when
> searching for the sender's photo in the address books (if you've it enabled).

I've disabled showing the sender photo, so I guess that this is not the cause.

Still, Evolution could be blocking WebKitWebProcess. I have 2.7 GiB of Emails.

Created attachment 1237103 [details]
Result of running $ gdb --batch --ex "t a a bt" -pid=`pidof WebKitWebProcess` &>bt2.txt

Could this be caused by GnuPG when checking signatures? I've enabled the GnuPG feature to search for unknown keys on the web and download them if available.

Created attachment 1237104 [details]
with partially rendered message: $ gdb --batch --ex "t a a bt" -pid=`pidof WebKitWebProcess` &>bt3.txt

Actually, I'm seeing a different version of this bug too: Sometimes evolution stops rendering the message after it started. Only the message header is drawn, but with an incorrect font (black font on dark gray background with Adwaita:dark theme). The message content isn't drawn, instead I see just one empty line with white background. After some time the message is drawn completely.

> Could this be caused by GnuPG when checking signatures? I've enabled the
> GnuPG feature to search for unknown keys on the web and download them if
> available.

Probably no, because many messages don't have PGP signatures and the issue still happens.

(In reply to Christian Stadelmann from comment #19)
> Sometimes evolution stops rendering the message after it started. Only the
> message header is drawn, but with an incorrect font (black font on dark gray
> background with Adwaita:dark theme).

Right, it's an indication that the WebKitWebPorcess is busy with something and cannot react to the tasks the evolution requested to be done.

Both of your bactraces show the main thread of the WebKitWebPorcess being busy in a hyphen code, which is bug #1402586. As it's Davide's bug report I believe it's the same here as well, thus I mark this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 1402586 ***