GNOME Bugzilla – Bug 750963
Evolution IMAP backends always raise error infobars on network reconnect ("Error fetching message headers: Shutting down")
Last modified: 2015-11-26 09:44:59 UTC
1. Sit around in your gmail imap inbox 2. Disable your system's network (ex: fn+F5 to switch off wifi on a thinkpad) 3. Evolution knows it is offline, judging from status icons in the sidebar 4. Reactivate the network (ex: through fn+F5) 5. I always get a silly infobar telling me: Failed to refresh folder "foo@bar.com: name_of_currently_viewed_folder". The reported error was "Error fetching message headers: Shutting down".
Thanks for a bug report. I tried to reproduce it, but no luck. I was playing with the network-manager's connect/disconnect of a wired connection, the only currently active (available) connection in my system (the WiFi is disabled by a hardware switch).
I made some extensive changes within bug #745545, which didn't remove the error message, but the way the code is used now changes it quit much. I cannot tell whether it fixes also this issue, because I wasn't able to reproduce it even before. The target stable version with the change is 3.18.0. I'm setting this to need-info, with a plea to retest with 3.18.0 or later evolution-data-server version. Thanks in advance.
Created attachment 316281 [details] screenshots of the process with 3.18 Hi Milan, I tested this with Evolution 3.18 now. While I don't get the same error infobar at the same time as before, the core issue persists beyond cosmetic differences: infobars are shown at the wrong times, or not shown when they should be. See the attached tarball of screenshots (all neatly labelled) of what happens at each step in 3.18.2.
(In reply to Jean-François Fortin Tam from comment #3) > infobars are shown at the wrong times, or not shown when they should be. Thanks for the update. This is a known issue of the GtkInfoBar, bug #710888. I tried to address this recently from within evolution [1] (3.18.3+ material). > See the attached tarball of screenshots (all neatly labelled) of what > happens at each step in 3.18.2. Okay, from your screen shots you blame about bug #758152. Despite the bug talking about resume from suspend, it's quite similar with going online/offline manually. There is also one little delay, around 5 seconds, before the evolution goes online after it's notified about it. It's because some notifications can be received multiple times and because it can take some time to the interfaces to fully initialize. Thus this subpart of your bug report is the bug #758152. By the way, if you look on the second screen shot, there is some ongoing activity on the accounts, which is the reason why the evolution doesn't claim full offline state (because some accounts are still disconnecting). [1] https://git.gnome.org/browse/evolution/commit/?h=gnome-3-18&id=9623308651 *** This bug has been marked as a duplicate of bug 758152 ***