Red Hat Bugzilla – Bug 494712
Evolution mailbox tree view stop responding to (un)collapse events after clicking on mail notification icon
Last modified: 2012-05-19 07:32:18 EDT
Description of problem:
After a certain amount of time, under conditions I have not yet ascertained, the tree view of Accounts/Folders (left-hand side of the Mail view in Evolution) refuses to collapse or expand subtrees, despite me clicking on the triangles. The tree is otherwise responsive, and I can select what folders are show.
Version-Release number of selected component (if applicable):
This reminded me of an upstream bug  though you do not the same steps with Shift/Ctrl and mouse as is mentioned in the bug. Can you expand/collapse when using keyboard only? (Shift+Arrow left/right when standing on the expandable node.)
Could you try to attach here backtrace of such broken state, just in case there will be something shown, even I doubt it. Just install debug info packages for gtk2, gtkhtml3, evolution-data-server, evolution, evolution-exchange (if you use), and possibly other evolution-related packages in use and then attach here result of this command (feel free to delete private information from there, if any):
$ gdb --batch --ex "t a a bt" -pid=PID
where PID is Process ID of Evolution process. Thanks in advance.
Created attachment 339194 [details]
gdb output requested
Attached is the output from gdb generated by the command given above acting on the broken state. Some of the symbols are missing, I only installed the debuginfo packages missing. Hope it is of some use.
...Sorry, make that "I only installed the debuginfo packages mentioned in Comment #1"...
I saw this myself the other day but did not investigate. The expander triangle was completely unresponsive. Didn't even change color in responsive to mousing over, which tells me the widget was not receiving input events for some reason.
Thanks for the back trace. It shows only that the evolution is idle, thus as Matt said, might be something wrong with a state of the widget itself.
When Matt mentioned "not receiving input events", is it for all keyboard and mouse events, or only for some of them? Will disable/enable any account from Edit->Preferences recover the tree from this unresponsive state? (Maybe create some fake maildir account for tests only, instead of playing with the real account. The only important thing is that the account should influence the left tree, by adding there some nodes.)
I'm trying to figure out some pattern when this happens and what are the circumstances.
(In reply to comment #5)
> When Matt mentioned "not receiving input events", is it for all keyboard and
> mouse events, or only for some of them? Will disable/enable any account from
> Edit->Preferences recover the tree from this unresponsive state? (Maybe create
> some fake maildir account for tests only, instead of playing with the real
> account. The only important thing is that the account should influence the left
> tree, by adding there some nodes.)
The entire tree view widget appeared to not be receiving input events, not just particular accounts. I could not interact with it in any way, neither by mouse nor keyboard. I didn't try disabling and re-enabling accounts but I suspect it wouldn't make a difference; it felt like a GTK+-level issue. Unfortunately, I was busy with something else at the time and just restarted the app.
No idea how to reproduce this, but if it happens again I'll dig deeper.
> I didn't try disabling and re-enabling accounts but I suspect it
> wouldn't make a difference; it felt like a GTK+-level issue.
No, it doesn't make a difference.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Still seen with:
but I can recall seeing it in other applications, too. Reassigning to gtk2.
*** Bug 509836 has been marked as a duplicate of this bug. ***
I don't know if this will help fixing the bug, but I found a way to always reproduce it:
When receiving new mail, an icon in the notification area will blink, if you click it to remove the notification you'll trigger this bug.
(I also explained that in bug 509836, duplicate of this one)
I can confirm Comment #11.
Bug exists in rawhide:
Still occurs when clicking on the mail notification icon, so disabling the plugin can help with avoiding this problem.
Filed upstream in https://bugzilla.gnome.org/show_bug.cgi?id=601080
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
I also have this bug, however, the bug happens for me even when I don't click on a notification window.
The bug is only present when using the mouse to expand or collapse tree. When using SHIFT+Arrow I have no problem.
A weird behaviour is when I try various times expanding a folder it sometimes work's, but when I click on any of the sub-folders the tree collapses again.
I've noticed the arrow (which is white with a black border) sometimes fills up in solid black (after attempting expansion of folder's) that's when I have the weird behaviour's of clicking on some other folder and trees expanding and collapsing.
Not an easy bug to explain, will however be happy to provide additional information.
Btw using clean install of FC12 and updated to latest versions available in repo.
# rpm -qa | grep evolution
(In reply to comment #16)
> I've noticed the arrow (which is white with a black border) sometimes fills up
> in solid black (after attempting expansion of folder's) that's when I have the
> weird behaviour's of clicking on some other folder and trees expanding and
Your description reminded me of an upstream bug  which is pretty the same and makes me believe this is not Evolution's bug, but gtk+ bug. I'm moving this one to gtk+.
(In reply to comment #17)
>  https://bugzilla.redhat.com/show_bug.cgi?id=541590
Hrm, I meant
*** Bug 547843 has been marked as a duplicate of this bug. ***
Ok I think i've identified source of problem. I am running synergy and when I kill it issue is gone.
Could people sufering from this bug confirm if they are using synergy and if killing it solves problem?
On another note, synergy is cauing quite a few problem bug 546267 is also mouse and synergy related.
I'm NOT using synergy.
Using gtk2-2.18.5-3.fc12.i686 from updates-testing repo (may-be that then?)
I am not using synergy, and so far the only way for me to reproduce the issue is still how I described it in comment #11.
What does synergy have in common with the notification area? Maybe this could give some pointers.
$ rpm -q gtk2
I killed synergy, and the issue went away.
Any idea what the connection is?
(In reply to comment #20)
> Could people sufering from this bug confirm if they are using synergy and if
> killing it solves problem?
> On another note, synergy is cauing quite a few problem bug 546267 is also mouse
> and synergy related.
I wrote about the synergy connection in upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=601080 a month ago including the symptoms in bug #54267. It may not be *the* cause of these problems, but it's a pretty easy way to duplicate the problems.
I meant bug 546267 obviously...
Could anyone of you try to run evolution under valgrind
$ valgrind evolution
with installed debug info packages for evolution, evolution-data-server, glib2, gtk2 and see whether it'll show some invalid reads or something like that? All that "it sometimes does that and sometimes not" seems to me as reading of some uninitialized memory. Just a guess.
I did not have any problem till i tried to install openoffice.org-langpack. After the installation, this problem starts. I tried to remove the langpack but could not find it with rpm -qa. Guess there must be some lib files causing this issue. Any idea?
*** Bug 550660 has been marked as a duplicate of this bug. ***
See bug 547924 for a related issue.
Given that at least some of us neither use nor has synergy installed, but can still _always_ reproduce the problem very easily (see comment #11 from July), couldn't we thus conclude that the problem must be in something used by both synergy and evolution (or the notification area)?
For those that have synergy installed and see the problem:
can you reproduce the bug with the method described in comment #11? If yes, can you then test if it goes away when killing synergy?
If so, I think we could say that the problem is not caused by synergy (we that don't use it can reproduce it too), but that it gets fixed when killing it. It may then be worth looking at what happens when killing synergy (maybe the state of the view tree is reset, or something...).
I started experiencing this bug today for the first time. As far as I know I haven't run yum update for about a week, so I don't what might have changed on my system to trigger it. I never had the problem before today. It's just as described in the other reports, clicking the tree triangles does not result in an expand or collapse. The tree appears permanently stuck in the condition it was in yesterday.
I'm assuming I don't use synergy, since I have no idea what it is. :)
Has anyone found a work around that will allow me to access folder in collapsed areas of the tree until a fix is released? I've been playing around with Evolution for half hour and so far haven't found a way to pry open the collapsed trees. :(
Oh, found the work around, if you shut down Evolution completely and then restart, the tree appears to work normally again for a while.
I've encountered this bug as well on a recent install of Fedora 12 with the latest updates installed. Haven't yet figured out exactly what triggers it, but it seems to be happening more frequently since I installed synergy yesterday. (It did happen a couple of times in the last week before I installed synergy.)
There are GTK+ patches under evaluation for this issue here:
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
It's still there in F14 (evolution-2.32.0-2.fc14.i686)
I'm reopening and setting this to Fedora 14 per the previous comment.
The upstream bug from comment #35 is also still opened.
Evolution is dropping all status icons in Fedora 15 (per GNOME 3 requirements) so this bug will obsolete itself in six months anyway.
But F14 will still be supported for another 6 months after GNOME 3 is out, and maybe Red Hat will even support it for a longer time in their distros (?).
*** Bug 658213 has been marked as a duplicate of this bug. ***
*** Bug 681365 has been marked as a duplicate of this bug. ***
Anyone still experiencing this, or can it be closed as UPSTREAM?
(In reply to comment #43)
> Anyone still experiencing this, or can it be closed as UPSTREAM?
I haven't seen this for a while, to be honest. So, I'm good with UPSTREAM.