After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 601080 - Evolution mailbox tree view stop responding to (un)collapse events after clicking on mail notification icon
Evolution mailbox tree view stop responding to (un)collapse events after clic...
Status: RESOLVED DUPLICATE of bug 562839
Product: evolution
Classification: Applications
Component: Mailer
2.28.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2009-11-07 15:52 UTC by James
Modified: 2009-12-29 23:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description James 2009-11-07 15:52:33 UTC
After clicking on Evolutions "new mail" icon in the notification area, the tree view of accounts and folders in the Evolution mail window will no longer (un)collapse in response to the arrows being clicked.

Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=494712
Comment 1 sim909 2009-11-09 23:26:31 UTC
Same thing here, but the problem is not triggered by any action on my part, it always happens. Problem appeared right after upgrading to Ubuntu 9.10 from 9.04 (64 bit versions). 

Below is my description and understanding (as a pure user) of things:

Normal behavior would be for the little triangle shaped arrow to turn from white to black whenever mouse hovers over it, then turn back to white when mouse hovers away. Being black essentially means that it is selected, so left clicking on a black arrow means the corresponding folder is expanded/collapsed.

What happens now is that hovering over- or away from- an arrow never changes its color, i.e. its "selected state", and in my very very humble opinion, this is the heart of the matter. So, if I click on a white arrow, the corresponding folder in the main mail window is shown, but the folder is not expanded/collapsed in the side panel. Sometimes I manage to turn an arrow black (see below for more on this), then 

1- the arrow stays black when I hover away from it, and it turns white when with the mouse I hover away from the whole side panel (e.g. when I hover over the main mail window)

2- pressing esc key turns the arrow white

3- if I repeatedly click on the black arrow itself, the corresponding folder repeatedly and consistently expands/collapses, remaining black

4- if I click anywhere else within the side panel (if I move away from the panel case 1- above kicks in), the folder corresponding to the black arrow will expand/collapse. Arrow will stay black if the folder is being expanded, it will turn white if the folder is being collapsed


Now on ways to turn the arrow black:

a- sometimes left clicking on it, maybe a number of times, turns it black, but without expanding/collapsing the corresponding folder. This is not very consistent and I haven't figured out a pattern yet

b- right clicking on a white arrow shows the context menu, then if I press the esc key with the mouse still over the arrow area, the context menu disappears and the arrow is left in a black state. This is very consistent, as long as in the process the mouse stays within the area of the arrow

I am running evolution version 2.28.1-0ubuntu2, libgtk2.0-0 v. 2.18.3-1ubuntu1 (not sure if relevant)
Comment 2 sim909 2009-11-09 23:30:36 UTC
Forgot to mention:

I have no problem expanding/collapsing with the keyboard

I have no problem expanding/collapsing e-mail threads in the main e-mail window, both with mouse or with keyboard: the corresponding arrows never change color, but they behave as expected
Comment 3 Matthew Barnes 2009-11-10 05:02:14 UTC
Confirming comment #0, though near as I can tell this is a GTK+ issue.

Clicking the blinking icon triggers a gtk_status_icon_set_visible (status_icon, FALSE) call from Evolution, and I suspect the problem may lie in GTK's implementation of that.  I see nothing else suspicious looking in the Evolution code that could lead to this.
Comment 4 Harold Campbell 2009-11-17 22:45:31 UTC
I'll throw out a second that this is a problem in GTK+ or below. At work I see this problem. At home I do not. At work the problem desktop runs synergys. At home it does not. As soon as I kill synergys the problem goes away. Reproducable every time.

I also see odd behavior in gvim. When in insert mode gvim is totally unpredictable about whether it hides the mouse pointer or not. Often moving the pointer through the window the pointer will be hidden. Sometimes not. Again, if I kill synergys the problem goes away.

These problems became evident with Fedora 12, so GTK+ 2.18. F11 has 2.16.
Comment 5 sim909 2009-11-18 00:49:14 UTC
I don't have synergys, don't have gvim, and the problem is always there and only with evolution. 
Not trying to say that it is not gtk+ fault, don't know enough to judge. 

My question would be: how can we fix the issue? Is this the wrong place? Where should I turn to?

thanks!
Comment 6 Milan Crha 2009-11-30 12:20:33 UTC
This is gtk+ issue, as I was able to reproduce this almost a year ago with a libgweather, see bug #562839.

The difference between left folder tree and the message tree is that the left folder tree is GtkTreeView widget, whereas the message tree is ETree, which is a special Evolution widget.

*** This bug has been marked as a duplicate of bug 562839 ***
Comment 7 sim909 2009-11-30 17:41:57 UTC
Although bug 562839 appears to be similar to this one, on my system I do not suffer from bug 562839 (I followed all the instructions carefully and more than once, all is behaving normally), but I do suffer from this bug 601080, so I am not sure either bug is really a duplicate of the other. 

Regardless, I would like to know if I can help in any (limited...) way trying to fix the problem, it is quite annoying although not a showstopper.
Comment 8 andrew 2009-12-29 23:26:41 UTC
I observe the same problem behavior as Milan Crha described in #562389, but with the folder tree in Evolution. I also second Harold Campbell's observation in comment #4 that the problem only appears when the 'synergys' keyboard+mouse sharing server is running. This worked fine in F11, showed up as a problem when I upgraded to F12.