GNOME Bugzilla – Bug 569765
Non-matching selected message won't leave search folder
Last modified: 2009-04-03 22:42:56 UTC
Please describe the problem: I have set up a Gmail-like workflow with Evolution. All my mail stays in the physical Inbox folder, and I have a search folder that shows all messages with a label I call "Untriaged". My mail workflow is to read a message in the search folder, act on it if necessary, and remove the label. Since the message no longer matches the search folder query, I expect it to disappear: immediately, or if the search folder has "Include threads" enabled, when I press F5. (This latter behavior is a feature of the patch in bug 557348 comment 53.) However, if the threaded view is enabled in the message list, the message does not disappear. Steps to reproduce: Starting from an empty home directory: 1. Create a search folder "Important" with the Inbox as its sole source and the single criterion "Label is Important". Leave "Include threads" set to "None". 2. Restart Evolution so the search folder appears (bug 564953). 3. Post a message to the Inbox. 4. Label the message Important. 5. Open the Important search folder. 6. Enable "View" -> "Group By Threads". 7. Right-click the message and select "Label" -> "None". Actual results: The message remains in the search folder's message list. (In my controlled test in a new home directory, all of the message's fields in the message list blank out and the preview pane changes to say "Unable to retrieve message". This does not happen when I follow the same procedure on my personal Evolution instance. I don't know the reason for this difference, but I don't think it's relevant.) Expected results: The message disappears from the message list. Does this happen every time? Yes. Other information: I think this is a side effect of the patch for bug 467892, which keeps the selected message in the message list even if it is removed from the folder! I will attach a patch. If "Group By Threads" is disabled, the problem does not occur. This is apparently because the non-threaded view has an extra sanity check to throw out messages no longer in the folder.
Created attachment 127513 [details] [review] Fix: Don't keep a selected message that is gone from the folder
Created attachment 127606 [details] [review] Fix, updated to apply cleanly
Hmm, this would work as usual on regular folder. On vfolder, it might behave as you had expected. But I think Milan should have a look
Milan: review?
OK, I didn't test it, but sure, it looks good, but one important thing: (In reply to comment #0) > [snip] > Since the message no longer matches the search folder query, > I expect it to disappear: immediately > [snip] most people will disagree with you, they do not want this to happen immediately, for the filter like "unread messages", with an automatic "mark as read" you wouldn't be able to read a message, mostly when the timeout is short. Nonetheless, this belongs to the bug #562912. Feel free to commit this patch to trunk.
(In reply to comment #5) > (In reply to comment #0) > > [snip] > > Since the message no longer matches the search folder query, > > I expect it to disappear: immediately > > [snip] > > most people will disagree with you, they do not want this to happen > immediately, for the filter like "unread messages", with an automatic "mark as > read" you wouldn't be able to read a message, mostly when the timeout is short. IMNSHO, the right way to fix the infelicitous behavior with "unread messages" vfolders/searches is to avoid marking a message read until the user has actually /read/ it. E.g., mark the message read when the user deselects it in the message list or closes its window after having it open for the configured timeout. A separate decoration (e.g., italics) could be applied to the message-list row after the timeout to tell the user this is going to happen so he/she won't be surprised. Trying to hack the generic mechanisms (searches, vfolders, and message list) to sometimes keep a message that truly doesn't match is never going to completely solve the problem and is going to create lots of others along the way (like this one). But that's a topic for a separate enhancement request. > Feel free to commit this patch to trunk. I'm not a committer. Would someone with the power please commit it?
committed as r37493. Thank you very much for the patch!