GNOME Bugzilla – Bug 677635
Vanished message list with filled preview panel
Last modified: 2013-09-13 01:06:49 UTC
I got couple times to a state where message list is empty and preview panel shows message I was staying on before this "oh my god" thing occurred. Looking more closely around, I see the folder in folder tree is suddenly unselected, applications title bar reads "Mail - Evolution" instead of previously shown "folder name with counts - Evolution". a) go to a remote folder (still my IMAP account) b) preview panel being on c) move through messages which are not downloaded yet, thus there is "Retrieving message" shown for few seconds d) till it's retrieving, move to the next message, thus new message is started retrieving e) repeat d) for 5-6 times, there are shown more activities in status bar Suddenly, message list is empty, preview panel is filled. Hard to tell whose feature of you too this is. :)
One more observation: I just start evolution, and it opens in IMAP folder with selected message which was selected when I closed evolution. I see in status bar "Retrieving list of folders for xxx". I do not touch anything and let it be. When this list of folder retrieval is done the message list is vanished, like I described above. There are also two critical warnings emitted on console, but I do not think they are directly related (see bug #677642).
I divided this into two issues, the one from comment #1 is filled as bug #678901 now.
I think this has been caused by the folder selection automatically jumping to another folder after folder summary has been updated. This "jump" probably didn't emit some signal and thus view EMailDisplay was not cleared. This bug seems to be fixed now and I'm not able to reproduce the issue described in comment #2. Is the bug still reproducible for you, Milan?
Yup, I just saw it. My steps are probably easier: a) move between folders and do not wait till the operation is done like setting multiple message as read, then select one message and move out of the folder b) repeat a) for couple times (various folders) c) select folder which has no message selected (as saved in config), or just select account node (or with exchange the "Mailbox - User Name" account, which is not selectable. d) when all the piled operations will settle (aka no activity in status bar), sometimes the preview shows message which I chose in some previous folder, while the message list is completely empty, because I'm on the account node I can them move between account nodes and the preview will still show the same message.
Created attachment 219215 [details] [review] Patch I was able to reduce the steps for reproducing this issue: 1) use IMAP+ 2) select a very big email that is not yet downloaded 3) while the email is downloading, select account node in folder list 4) wait until the message is downloaded 5) message is displayed in preview pane although the message list is empty This patch does two things to fix the issue: 1) Sharing a single GCancellable for the entire process of retrieving message and parsing. Before retrieving and parsing were using two GCancellables, because they each create a new EActivity. This shared GCancellable can be stored in EMailReaderPrivate and thus selecting another folder or message while parsing will interrupt the process. Before only retrieving of message could be interrupted by cancelling the GCancellable stored in EMailReaderPrivate. 2) Forces MessageList to ALWAYS emit "message-selected" signal from message_list_set_folder(). Before, it was emitted only when a valid CamelFolder was passed to the function, but account nodes are not valid folders (NULL is passed). Emitting "message-selected" signal even when no message is selected makes sense to me, because null message selection is still a message selection. EMailReader automatically stops running GCancellable when a message is selected.
Thanks for a patch. The account node trick seems to be it, I think I did that too, I only didn't think of it. I recall the ESource::changed signal also selected an account node. The patch seems to work fine, please commit. Thanks.
Comment on attachment 219215 [details] [review] Patch Maybe write an explanation comment before the g_signal_emit() why it's called always.
Comment on attachment 219215 [details] [review] Patch Added an explanatory comment and committed to master as 0568c36 http://git.gnome.org/browse/evolution/commit/?id=0568c36bde3fde0baaf5602d0a22fcf5749d27d9