GNOME Bugzilla – Bug 578245
View settings for threads getting lost
Last modified: 2011-12-13 22:52:07 UTC
Please describe the problem: Evolution tends to loose the status of expanded and collapsed threads in thread view. Steps to reproduce: 1. Use 'Group by threads' and collapse a few of them 2. Switch to another folder 3. Switch back to the first folder Actual results: All threads are expanded again Expected results: Views should be saved, collapsed/expanded threads should remain as they were before. Does this happen every time? Yes, but I haven't found a pattern. Sometimes it's happening several times a day, sometimes after a couple of days. Other information: I'm a long time evolution user and I've never seen this behavior in a version except of 2.24.x
(In reply to comment #0) > Does this happen every time? > Yes, but I haven't found a pattern. I think I have found it. The settings get lost after searching a folder. As soon as I remove the search terms, view settings are lost. No need to browse to another folder, try yourself.
confirmed with Evolution 2.28.0.
Thanks for a bug report. It's still there in actual master (~2.30.0), but it has its reason. Sort of a reason. I'm wondering what you are expecting to see, or how it should behave, because the folder view is saved even with the search entered, between evolution sessions, so next start you open the folder in the same state as you left it. Are you suggesting to not save expanded state for folders where search is activated at all? Or use another file/section name for a folder with search activated? I do not think having saved an expanded state for every search term/type makes any sense, so share this between searches may be better. To return to the beginning, the "reason" is that it is not differentiating between "with search" and "without search". It is not also able to distinguish between message removed and message hidden state (actually it is, but the complexity of the code doesn't worth it). So it's rewriting whole expand state on the actual folder view whenever you open it or the message list is regenerated. I guess the way of saving expand state specially for search activated and deactivated makes most sense. What do you think?
I don't care about the state when search is activated. I guess it makes sense to expand everything because then you can see the detailed list of results. Imagine you search for a subject and someone changed the subject deep within a nested thread. You will ether see a collapsed thread that does not match the search or -if only the matches are shown- the nested mails will raise to the top level. Nether is intuitive, so it might make very well sense to always use a plain list when a search is active. What I do care about is that as soon as I leave the search, the folder should return to it's previous state. If you have a real huge folder like fedora-devel-list (currently ~ 12.000 mails on my computer) and 200 threads are collapsed because they are never ending discussions that you don't want to follow. One search and the collapsed/expanded state you have been working with is ruined and you can start all over again. It is very unlikely that you will be able to ever reach the exact previous state again.
OK, thanks for the update. Not saving expand state when searching in the folder seems fine for me too, even when seeing it between sessions. So it'll load state, but not save it.
Downstream bug report from 3.0.1 mentioning the same issue: https://bugzilla.redhat.com/show_bug.cgi?id=708290
Created attachment 189001 [details] [review] evo patch for evolution; There was a special issue in 3.0.1, the folder used after XDG migration wasn't created, thus any attempt to save/load thread expand state failed. This patch does couple things: a) create the folder for the expand state saving in case it doesn't exist b) do not save expand state when searching is active c) always expand all when searching is active d) use common function for expand state loading instead of writing similar implementation in message_list_setup_etree()
Created commit efb9a4b in evo master (3.1.2+) Created commit 2b4ed00 in evo gnome-3-0 (3.0.3+)
Milan, is this really fixed? I'm using evolution-3.0.3-1.fc15.x86_64 on my Fedora 15, which contains your fix (I double checked the sources, it is there), however, view setting for threads are still lost. For example (steps to reproduce the bug): 1) collapse a couple of threads in INBOX 2) searching for something 3) clear the search box 4) all threads are expanded (including the ones, which were previously collapsed) I even tried creating a new user account on the system and configuring the Evolution from the start and it was still the same. Any clues to what goes wrong?
I installed Fedora 16 and tried the latest version of Evolution in there: evolution-3.2.2-1.fc16.x86_64 The same problem persists. Evolution doesn't remember the view settings for the threads (collapsed / expanded). Should I file a new bug or should someone reopen this one?
(In reply to comment #9) > For example (steps to reproduce the bug): > 1) collapse a couple of threads in INBOX > 2) searching for something > 3) clear the search box > 4) all threads are expanded (including the ones, which were previously > collapsed) I think it was a request to expand threads when searching. If you collapse them while searching they are kept collapsed on search clear for me (git master, before 3.3.3, and 3.2.3, which is pretty the same as 3.2.2 in this area).
Milan, (In reply to comment #11) > > I think it was a request to expand threads when searching. If you collapse them > while searching they are kept collapsed on search clear for me (git master, > before 3.3.3, and 3.2.3, which is pretty the same as 3.2.2 in this area). thanks for taking the time and replying to my comments. Yes, it was requested that threads should be expanded while searching, however, my issue is different. Let me try to describe it again. 1) collapse a thread in INBOX (e.g. "Orphaned packages") 2) searching for something that doesn't involve the previously collapsed thread (e.g. "Boot issues") 3) clear the search box 4) the thread (e.g. "Orphaned packages") is expanded This gets really annoying if you are on a mailing list where your are not interested in some long threads and you collapse them. After searching for something completely unrelated to the collapsed threads, they are expanded again (upon clearing the search box). Do you see what is my problem?
(In reply to comment #12) > Let me try to describe it again. > > 1) collapse a thread in INBOX (e.g. "Orphaned packages") > 2) searching for something that doesn't involve the previously collapsed thread > (e.g. "Boot issues") > 3) clear the search box > 4) the thread (e.g. "Orphaned packages") is expanded Right, that's exactly the problem that made me file this bug.
(In reply to comment #12) > Do you see what is my problem? Yup, understood. (In reply to comment #13) > Right, that's exactly the problem that made me file this bug. Hmm, I was about to request a new bug report for this, but you've right, either something got lost during the time or the patch doesn't work fully. I'm reopening this.
Created attachment 203319 [details] [review] evo patch ][ for evolution; I'm not sure how I tested this, but I obviously forgot on one place. This is completing the previous patch. It loads collapse state from a disk, rather than reusing the in-memory state, when regenerating message list while searching for something.
Created commit bb1e5f6 in evo master (3.3.3+) Created commit 23bc4bd in evo gnome-3-2 (3.2.3+)
(In reply to comment #16) > Created commit bb1e5f6 in evo master (3.3.3+) > Created commit 23bc4bd in evo gnome-3-2 (3.2.3+) Milan, thanks for making the patch and resolving the issue! I'll try to test it ASAP.