GNOME Bugzilla – Bug 467892
"Unread Messages" causes mail that you read to disappear
Last modified: 2013-08-09 22:30:23 UTC
Version: 2.10 When setting the show filter to "Unread Messages" causes Emails that you read to disapear before you can read them, leaving you with an open email with no content. I would think the normal behaviour would would mark the email read after you close the email and not as you open it. Distribution: Fedora release 7 (Moonshine) Gnome Release: 2.18.3 2007-07-02 (Red Hat, Inc) BugBuddy Version: 2.18.0
does not happen here. can you provide exact steps how to reproduce this?
Reproducing Bug: 1) open evolution 2) select SHOW: "Unread Messages" instead of "All Messages" 3) open an email Effect: Email opens for a split second and then the contents of the email disappears along with the entry in the email list, leaving you with a blank window. The only way to read the email is to go back and select All Messages once again and the re-open the email Reproducible: YES, I have tried this with all my systems that have Fedora 7 with the current updates. I have not verified with a vanilla install as of yet. Current RPM: evolution-2.10.3-2.fc7 See attachment for location of the SHOW selection
Created attachment 93910 [details] jpeg describing the location of changing the SHOW filter for Unread Messages
is this still an issue?
Yes this is still an issue. If I select "Unread Messages", as soon as I click on a message, a window pops up with the email inside and then it disappears and I'm left with a blank window. Thanks in advance
still an issue in evolution 2.21.4
*** Bug 460441 has been marked as a duplicate of this bug. ***
*** Bug 483930 has been marked as a duplicate of this bug. ***
I have an issue which might be related to this: on an IMAP account, when new mail is received, the view is updated again and all the mail that were read (after having switched to show only unread messages) disappear. Including the one I'm reading...
I can reproduce this very easily with two mail windows, when set in one the "Unread messages" filter and making changes in that folder in the second window, then the first window refreshes its view on each change. I would like to propose this behavior: a) There is a change on the folder not caused by the use (like new mail arrival, change from other instance and so on). In this case always keep focused message there, regardless whether it belong to actual filter or not. b) Users invokes refresh of the view (like F5 or similar). In that case hide focused message when it doesn't belong to actual filter. What do you think? Will it be better or not?
Milan: sounds good to me.
Created attachment 108350 [details] [review] proposed evo patch for evolution; I read the code more deeply and it shows the b) is wrong, the refresh folder doesn't do exactly this, it will only when the change on the folder will be detected, and only when the change will be on the other message(s) then selected. So I did this unconditionally.
Milan, I think your change is positive but the bug isn't fixed, for the following reasons. (*) When you double click a message, it has a hidden message list into it which races between the opened mail's timeout to mark as read. So. Even with your patch this occurs. One way to solve the problem is that make the hidden message list in the message browser without the search, so that it has all the messages. But yeah, the Forward/Next button on the message wont be in sync with the message list shown on the view.
Ahh, I see, I misunderstood the bug, I'll extend my patch then.
I noticed other issue with my initial approach too, it always keep actual message in a view, so when changing filter then no way to get rid of the focused mail. I will think about this a bit more then. I'm not sure, but maybe one possible way can be to make an "Unread Messages" filter as a special filter, like "Hide Deleted Messages" is, and does this the "keep unread messages" code only for these messages. Even it can still have some issues. Btw, personally I like the idea to not inherit a search string to new message window, but as you said, it also means the prev/next buttons will come through other messages than through those initially visible in message view. I'm not sure whether that's a problem or not, maybe it isn't so big deal, because you do not see the list itself and you can switch back to main window and change the filter anyway.
It could be a problem.. May be not. I tried all the approached and this seemed to be a closer bet. But really I wanted to rewrite those bits after my disk summary or so with a clear approach. Currently when you open a new window, it sort of increases your memory req. IIRC Notzed was for removing the Prev/Next buttons and it had lots of oppositions and I assumed that it is a most used thing.
Created attachment 109763 [details] [review] proposed evo patch ][ for evolution; Updated patch. As we discussed on IRC, the search filter is not inherited in the new window, so the message will not disappear there. I also updated the old part, it will keep the actual message only when called from folder_changed event and if there was any filter set in previous rebuild. Otherwise it works same as before.
Milan, seems fine. Commit to stable/trunk.
Committed to trunk. Committed revision 35454. Committed to gnome-2-22. Committed revision 35455.
*** Bug 446573 has been marked as a duplicate of this bug. ***
Reopening as per comment #17 in bug #535749.
Created attachment 112673 [details] [review] proposed evo patch ]I[ for evolution; This time, the patch returns ability to inherit search filters when opening message in new window, and also sets the UID of the actually selected message to be present after the regeneration of the list event it may not be the part of the list anymore. Not so nice, but should work this time a bit better.
gross hack :). Anyways, I dont see a better way anyways. Commit it.
Committed to trunk. Committed revision 35640. Committed to gnome-2-22. Committed revision 35641. I also cannot think of any better solution, it's really bad.
It may be a gross hack and really bad, but it does work. Thanks!
*** Bug 326157 has been marked as a duplicate of this bug. ***