After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 467892 - "Unread Messages" causes mail that you read to disappear
"Unread Messages" causes mail that you read to disappear
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.22.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 326157 446573 460441 483930 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-18 08:01 UTC by Robert F. Chapman
Modified: 2013-08-09 22:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
jpeg describing the location of changing the SHOW filter for Unread Messages (30.83 KB, image/jpeg)
2007-08-18 20:16 UTC, Robert F. Chapman
  Details
proposed evo patch (2.57 KB, patch)
2008-03-31 16:01 UTC, Milan Crha
needs-work Details | Review
proposed evo patch ][ (3.81 KB, patch)
2008-04-23 12:44 UTC, Milan Crha
committed Details | Review
proposed evo patch ]I[ (5.54 KB, patch)
2008-06-13 11:42 UTC, Milan Crha
committed Details | Review

Description Robert F. Chapman 2007-08-18 08:01:14 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
Comment 1 André Klapper 2007-08-18 11:24:55 UTC
does not happen here. can you provide exact steps how to reproduce this?
Comment 2 Robert F. Chapman 2007-08-18 20:15:35 UTC
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

Comment 3 Robert F. Chapman 2007-08-18 20:16:55 UTC
Created attachment 93910 [details]
jpeg describing the location of changing the SHOW filter for Unread Messages
Comment 4 André Klapper 2008-01-02 22:39:05 UTC
is this still an issue?
Comment 5 Robert F. Chapman 2008-01-04 16:29:03 UTC
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
Comment 6 Basilio Kublik 2008-01-09 02:52:49 UTC
still an issue in evolution 2.21.4
Comment 7 Basilio Kublik 2008-01-09 02:54:57 UTC
*** Bug 460441 has been marked as a duplicate of this bug. ***
Comment 8 Basilio Kublik 2008-01-09 03:00:00 UTC
*** Bug 483930 has been marked as a duplicate of this bug. ***
Comment 9 Vincent Untz 2008-02-29 15:04:58 UTC
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...
Comment 10 Milan Crha 2008-03-31 13:35:59 UTC
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?
Comment 11 Vincent Untz 2008-03-31 13:57:15 UTC
Milan: sounds good to me.
Comment 12 Milan Crha 2008-03-31 16:01:17 UTC
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.
Comment 13 Srinivasa Ragavan 2008-04-03 09:16:07 UTC
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.
Comment 14 Milan Crha 2008-04-03 11:46:22 UTC
Ahh, I see, I misunderstood the bug, I'll extend my patch then.
Comment 15 Milan Crha 2008-04-04 12:38:41 UTC
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. 
Comment 16 Srinivasa Ragavan 2008-04-04 19:38:40 UTC
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.
Comment 17 Milan Crha 2008-04-23 12:44:27 UTC
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.
Comment 18 Srinivasa Ragavan 2008-04-30 04:29:20 UTC
Milan, seems fine. Commit to stable/trunk.
Comment 19 Milan Crha 2008-04-30 09:54:01 UTC
Committed to trunk. Committed revision 35454.
Committed to gnome-2-22. Committed revision 35455.
Comment 20 Akhil Laddha 2008-05-20 11:14:36 UTC
*** Bug 446573 has been marked as a duplicate of this bug. ***
Comment 21 Milan Crha 2008-06-13 08:12:01 UTC
Reopening as per comment #17 in bug #535749.
Comment 22 Milan Crha 2008-06-13 11:42:08 UTC
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.
Comment 23 Srinivasa Ragavan 2008-06-15 17:09:46 UTC
gross hack :).

Anyways, I dont see a better way anyways. Commit it.
Comment 24 Milan Crha 2008-06-16 09:25:36 UTC
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.
Comment 25 Han Pilmeyer 2008-06-19 07:17:10 UTC
It may be a gross hack and really bad, but it does work. Thanks!
Comment 26 Hans Petter Jansson 2013-08-09 22:30:23 UTC
*** Bug 326157 has been marked as a duplicate of this bug. ***