Description of problem:
When I move to a particular e-mail (hosted on Exchange 2010, accessed via ews), the whole Gnome workspace, including Evo, becomes "frozen". Clicking on any other window will not work. I can still change the workspace (using workspace indicator extension) and do anything in any other workspace, but this one is frozen until I shut Evo down. Sometimes, it untangles itself after many minutes. Sometimes not.
The e-mail, which I cannot share here (unfortunately), has a single 81 kB attachement - a CSV file. It can be seen easily in Outlook.
Top does not really show any activity. Evo is not busy or anything, so looks like some sort of deadlock.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Click on the e-mail in question.
2. No preview.
3. Workspace freezes.
Whole workspace frozen.
Should not freeze.
Started some weeks ago?
One more thing. The "frozen workspace" behaviour is not the only way this bug manifests itself. Sometimes, it is just Evo that hangs. It displays "retrieving message <id>" down in the status bar and hangs. Clicking anywhere else in Evo does nothing.
This must be some kind of message display problem. I just turned preview off, positioned myself on the message and displayed source of it just fine (Ctrl + U). However, a double click on it (view), immediately hangs the interface.
Thanks for a bug report. I suppose the message's preview also causes high CPU usage. It would be good to install debuginfo packages for evolution-data-server and evolution, and get a backtrace of "running" evolution, like with:
$ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
It (the bt.txt file) can contain some private information, thus make sure you'll not expose any (I usually search for "pass" at least (quotes for clarity only)). I suspect that webkit got stock in accessibility/a11y code, I recall some upstream bugs related to it.
(In reply to Milan Crha from comment #3)
> I suppose the message's preview also causes high
> CPU usage.
When any of the hangs happen, CPU usage is practically non-existent.
Backtraces sent privately.
Thanks, the backtraces helped to identify the issue. It is the same as bug #1089966, see the bug #1089966 comment #2 for a workaround.
*** This bug has been marked as a duplicate of bug 1089966 ***