GNOME Bugzilla – Bug 581050
Can't expand mail accounts
Last modified: 2013-09-11 01:44:10 UTC
Please describe the problem: After evolution has been running for a while, my ability to expand the disclosure triangles beside mail accounts in the folder pane goes away. They highlight when the mouse pointer hovers over them, but clicking has no effect. Steps to reproduce: Actual results: Expected results: Does this happen every time? Yes Other information:
I confirm that I have also been having this issue for several weeks now and have been talking to folks on the Evo team about this. Solution in this case is to quit Evolution and start it again. Or... as a proactive measure, expand all your folders before the freeze happens. :-) (ok last suggestion isn't pretty.)
I've seen this once myself and have been asked about it several times, so confirming. Still have no clue what's causing it.
*** Bug 584738 has been marked as a duplicate of this bug. ***
Still present in 2.26. I'm surprised there aren't more duplicates of this bug, as I've now seen it on three different systems. In case the particulars of my setup are relevant, on each machine I have two IMAP accounts configured, both of which use TLS, and one spool account which gets mail from the mbox /var/mail/$username.
(In reply to comment #4) > Still present in 2.26. Even on 2.27.91 FWIW
Same here on 2.27.91. Frustrating as all heck!
This is most likely a GTK+ or ATK bug. If you have accesibility enabled, try turning it off and see if that makes a difference.
I always tun a11y stuff off so I think we can narrow down to GTK...
There's a Red Hat about this on file, assigned to GTK+: http://bugzilla.redhat.com/show_bug.cgi?id=494712 Report claims it's triggered by clicking the "new mail" icon in the notification area. Can someone confirm and also indicate your GTK+ version?
GTK version 2.17.7, but this has occurred in previous versions as well. I don't think its related to the mail notify icon. You can expand/collapse right away after you start Evo, but after about 10 minutes, it stops working. Regardless of the notify icon. I have started Evo, walked away without touching anything and come back and it's all locked. Having talked to srag, he also believed that this is a GTK issue. But where?
(In reply to comment #9) > Report claims it's triggered by clicking the "new mail" icon in the > notification area. Can someone confirm and also indicate your GTK+ version? Just had a notification icon and clicked it, expander still works.
*** Bug 593949 has been marked as a duplicate of this bug. ***
Same problem here in Evo 2.28.2.
Would someone please look into this. It has made evolution basically unusable as a mail client for me since I originally reported this issue. Restarting evolution whenever I want to expend a damn mail folder is not a solution!
Folder expansion/collapse is disabled after clicking on the notifier icon when mail is received, and ONLY after clicking on the tray icon. I've known about this problem for a while, so I've always been careful not to click the icon, and I've never lost the ability to expand or collapse folders. Recently my hand slipped, and here I am posting. Evolution 2.28 libgtk2 2.20
I just tested Felipe's comment #15, and after the expected period of time before collapsing/expanding would break passed and still able to expand/collapse. Thanks Felipe for identifying the exact symptom that causes it! Gonna be a hard habit to break not touching that notifier though. :-)
Felipe, you are a legend. Thank you!
Created attachment 160492 [details] [review] remove 'unrealize tray icon' It was caused by the change of the gtktrayicon-x11.c source codes and the unchange of the gtkstatusicon.c source codes. In the old code, the real 'remove work' of tray icon was done in gtk_tray_icon_unrealize. If we want remove tray icon, we should just gtk_status_icon_set_visible(icon, FALSE), as it calls gtk_widget_unrealize (priv->tray_icon). But now, the real 'remove work' of tray icon was done in 'dispose' function. If we want to 'remove' it, we should use g_object_unref (status_icon). In mail-notification.c, it calls gtk_status_icon_set_visible (status_icon, FALSE) before g_object_unref (status_icon); So before g_object_unref (status_icon) took effect, the tray icon related gdkwindow was already unrealized. In this case, tray icon was never removed and it effected the event in the em-folder-tree of evolution.
David, would be great if you can file the bug in gt+ module and attach the patch there so that it can be reviewed by the respective maintainers and the patch gets upstreamed..
(In reply to comment #19) > David, would be great if you can file the bug in gt+ module and attach the > patch there so that it can be reviewed by the respective maintainers and the > patch gets upstreamed.. There is such bug already, it's bug #562839 (and probably more). I'm moving this to gtk+ and the other marking as a duplicate of this, because of the patch availability for a long standing issue. Thanks David.
*** Bug 562839 has been marked as a duplicate of this bug. ***
Comment on attachment 160492 [details] [review] remove 'unrealize tray icon' Removing the unrealize call here should be safe, though I am not 100% sure I understand why it would have the negative impact that you are seeing.
Created attachment 161534 [details] [review] remove the grab in button_release_event The previous patch was reported to make side effect, it made the broken icon in the notification area. (https://bugzilla.novell.com/show_bug.cgi?id=604737) But I don't cannot reproduce it. I wrote a new patch here. In the original gtktreeview.c gtk_tree_view_button_release, when calls gtk_grab_remove, tree_view->priv->prelight_node will be set to NULL, so the real_expand_row or real_collapse_row will never be called. The patch move the gtk_grab_remove to the end of calling real_expand_row. I think it is the right place to call gtk_grab_remove. The tray icon seems never being destroyed thoroughly, even after g_object_unref (status_icon). The window is always exist. gtk_widget_unrealize (priv->tray_icon) in gtkstatusicon.c; ---> gtk_plug_unrealize in gtkplug.c ---> the group of the gtktrayicon window will be set to NULL As the tray icon window is not destroyed, when calls gtk_grab_remove in gtktreeview, it will read the tray icon window. Both of their groups were NULL (also means th default group), so it will call the *grab_notify*. Then LEAVE_NOTIFY will be called, in gtktreeview, it set prelight_node to NULL. My previous patch removes the unrealize calling in gtkstatusicon, so the window group of treeview window and tray icon window will be different. Another way of solving it is, when the window group was NULL (or default), we need not to call gtk_grab_notify_foreach (GTK_WIDGET (toplevel), &info); (in gtkmain.c:gtk_grab_notify). I test it, it also works. But I am not sure if there were other considerations of doing this now.
Moving to correct component.
Hi David, I am not reviewing the overall system effect of your patch in comment #23, I am hoping a gtk developer will weigh in on that. However if that approach is approved the patch needs to be modified. I think you need to maintain the gtk_grab_remove call at the same logical level - ie the patch currently changes if (event->button == 1) { gtk_grab_remove if (tree_view_priv_button_pressed_node ...) { } ... } to if (event->button == 1) { if (tree_view_priv_button_pressed_node ...) { gtk_grab_remove } ... } This will cause the problem that if the button release is done outside that widget then the grab will not be removed and the application will appear unresponsive as events will not be routed properly.
Created attachment 162163 [details] [review] updated patch move the gtk_grab_remove to the same logic
Great work on figuring out the exactly procedure for reproducing this! Here follows an ugly patch against testtreesort.c to have a test case for this: diff --git a/tests/testtreesort.c b/tests/testtreesort.c index a23b367..3860db0 100644 --- a/tests/testtreesort.c +++ b/tests/testtreesort.c @@ -97,6 +97,13 @@ switch_search_method (GtkWidget *button, gtk_tree_view_set_search_entry (GTK_TREE_VIEW (tree_view), NULL); } +static gboolean +foo (GtkStatusIcon *sicon, GdkEventButton *b, gpointer data) +{ + gtk_status_icon_set_visible (sicon, FALSE); + return TRUE; +} + int main (int argc, char *argv[]) { @@ -118,6 +125,15 @@ main (int argc, char *argv[]) gtk_init (&argc, &argv); + { + GtkStatusIcon *sicon; + + sicon = gtk_status_icon_new_from_stock (GTK_STOCK_NEW); + gtk_status_icon_set_visible (sicon, TRUE); + g_signal_connect (sicon, "button-press-event", + G_CALLBACK (foo), NULL); + } + /** * First window - Just a GtkTreeStore */ 1. Recompile testtreesort 2. Click on GTK_STOCK_NEW in your notification tray 3. Try expanding/collapsing branches. This should have broken.
(In reply to comment #26) > Created an attachment (id=162163) [details] [review] > updated patch > > move the gtk_grab_remove to the same logic I can confirm that this patch makes expanding/collapsing nodes work again after clicking the notification icon. There is one issue left with this patch, please compare before/after clicking the notification icon: Before: By repeatedly clicking on an arrow in the tree view, the node will expand and collapse repeatedly. After: This does not work anymore. I will try to investigate.
The above observation of course makes sense: by moving the call to gtk_grab_remove(), the leave-notify event to be received is just delayed. We need to determine whether this leave-notify event should be sent at all.
After some more debugging, I don't think this is a tree view bug. There's the following branch in gtk_grab_notify_foreach(): if (was_shadowed && GTK_WIDGET_HAS_POINTER (child) && gtk_widget_is_sensitive (child)) The problem is that this branch is taken when "child" is the tray icon after the tray icon has been hidden. So, after the tray icon has been hidden, GTK_WIDGET_HAS_POINTER() still yields true for the tray icon widget. The GTK_HAS_POINTER bookkeeping is done by gtk_main_do_event(), depending on received ENTER_NOTIFY and LEAVE_NOTIFY events. This is where we can observe the main problem, when the tray icon is set to invisible, a LEAVE_NOTIFY event is never received and thus the GTK_HAS_POINTER flag is never unset. The internal state is broken from now on. To test this theory, no tree view patches are needed, just this one will do: diff --git a/gtk/gtkstatusicon.c b/gtk/gtkstatusicon.c index dab6ff6..7f71a93 100644 --- a/gtk/gtkstatusicon.c +++ b/gtk/gtkstatusicon.c @@ -2302,6 +2302,7 @@ gtk_status_icon_set_visible (GtkStatusIcon *status_icon, { gtk_widget_hide (priv->tray_icon); gtk_widget_unrealize (priv->tray_icon); + GTK_PRIVATE_UNSET_FLAG (priv->tray_icon, GTK_HAS_POINTER); } #endif Of course, the above patch is a hack and not suitable to be committed. I am not sure what the right way of fixing this is. Reassigning to "gtk" component for investigation.
*** Bug 603960 has been marked as a duplicate of this bug. ***
*** Bug 615870 has been marked as a duplicate of this bug. ***
*** Bug 628423 has been marked as a duplicate of this bug. ***
*** Bug 629626 has been marked as a duplicate of this bug. ***
*** Bug 630820 has been marked as a duplicate of this bug. ***
*** Bug 631586 has been marked as a duplicate of this bug. ***
ref: https://bugzilla.gnome.org/show_bug.cgi?id=629626 The issue disappeared for me today, after upgrading to Ubuntu 10.10
Hm I noticed that if I make Suspend-to-RAM and Resume quickly, just keep laptop for a minute in Suspend-to-RAM mode, the bug doesn't occur on Resume. It seems to only happen if a laptop has been in Suspend-to-RAM mode for a longer time, like 8 or so hours (when I Suspend the laptop during the time when I sleep).
I can't reproduce it in Evolution 2.32.0.
I was wrong, the bug is still there. Please ignore my previous comment.
Yeah, it's still there and it seems to only happen when a new mail notification icon is clicked. I'm just saying this to scratch my original bug report statement and correct myself.
*** Bug 629106 has been marked as a duplicate of this bug. ***
*** Bug 632823 has been marked as a duplicate of this bug. ***
This was reported in Ubuntu: https://bugs.edge.launchpad.net/evolution/+bug/664596
Fabian: Feel free to set the "See Also:" field in such cases.
*** Bug 641005 has been marked as a duplicate of this bug. ***
Hi, this bug is really annoying. Can't David and Kristian analysis be thought out and a fix be found? Thanks. (I'm saying that because I just spent hours making the same conclusions as David, not aware of this bug report)
*** Bug 644769 has been marked as a duplicate of this bug. ***
Comment on attachment 160492 [details] [review] remove 'unrealize tray icon' Setting status to obsolete as superseded by follow-up-patch
*** This bug has been marked as a duplicate of bug 675835 ***