GNOME Bugzilla – Bug 352982
Threads jump around when messages are deleted
Last modified: 2013-09-13 00:52:19 UTC
If you use threaded view and Hide deleted messages, then start reading your mail from top to bottom and use the delete message to delete the first message in a thread, the thread jumps to another place, depending on the timestamp of the next message in thread... That's really annoying and has turned me to keep "Hide deleted messages" off. Now that in Evo 2.8 threads will be sorted according to their latest timestamp instead of first, this is less of an issue, still jumping around doesn't help reading mail. The thread may jump to its new place when the cursor leaves the thread for example. I've seen KMail had the same bug. Don't have the link to their bugzilla now.
well, as you already correctly stated, this only happens when deleting the oldest message of a thread, so evolution just resorts the threads. proposal?
(In reply to comment #1) > proposal? I suggested: The thread may jump to its new place when the cursor (ie, selection) leaves the thread for example. This works good enough, as with thread sorted based on their latest timestamp, this means threads can only jump back (unless new mail arrives), so they don't get in the way as you go down again. Another option is to somehow lock the threads's place until you leave the folder.
This was working correctly at one point in the past. See bug 203737. (It was originally broken, then at some point someone fixed it, and then apparently it's gotten broken again since then.)
Created attachment 71693 [details] [review] Tryout patch Behdad, can you try out this? Is this what you are expecting?
(In reply to comment #2) > (In reply to comment #1) > > proposal? > > I suggested: The thread may jump to its new place when the cursor (ie, > selection) leaves the thread for example. > > This works good enough, as with thread sorted based on their latest timestamp, > this means threads can only jump back (unless new mail arrives), so they don't > get in the way as you go down again. > ATM, A collapsed thread only comes up on a new message. If it is expanded, it is not modified. That is what I explained in my blog too. This specific issue occurs, only when you delete a old message in a thread (parent node). I have attached a patch. Ill explain the sequence. MESSAGE DATE ... - P1 June 11 - Parent June 10 - S1 Parent June 22 - S2 NODE June 24 - P3 June 09 - P4 June 08 ... with this patch appplied, if you delete node "Parent" the view remains the same. What you see is. MESSAGE DATE ... - P1 June 11 - P3 June 09 - P4 June 08 ... And nothing is selected after deleting the selection and so, the thread moved up to the right place, and the view remains same and wont jump around. Let me know your thoughts on this. > Another option is to somehow lock the threads's place until you leave the > folder. >
Created attachment 71773 [details] [review] Version 2 This fixes the cursor movement on hide_delete disabled(old behaviour).
Fixed to HEAD. Reviewed by Varadhan.
(In reply to comment #5) > And nothing is selected after deleting the selection and so, the thread moved > up to the right place, and the view remains same and wont jump around. Let me > know your thoughts on this. This is not exactly what I expected. This way there's no way I can completely delete the thread by just pressing the Delete button. But if threads are sorted on the latest timestamp, this works good enough. Your example uses the old sorting behavior though.
Delete Selected Thread is something, that I missed when I started using threads. Should be part there nearly. Threads are sorted on latest time stamp, if they are collapsed. When expanded, they still look same old way.
(In reply to comment #9) > Delete Selected Thread is something, that I missed when I started using > threads. Should be part there nearly. > Threads are sorted on latest time stamp, > if they are collapsed. When expanded, they still look same old way. You mean expanding a collapsed thread makes it disappear/jump too?! That's definitely not correct. Moreover, I never use collapsed threads. So I won't enjoy the new sorting order?
(In reply to comment #10) > (In reply to comment #9) > > Delete Selected Thread is something, that I missed when I started using > > threads. Should be part there nearly. > > > Threads are sorted on latest time stamp, > > if they are collapsed. When expanded, they still look same old way. > > You mean expanding a collapsed thread makes it disappear/jump too?! That's > definitely not correct. Not really. You expand a thread it will be moved to the original place from top, on the next resort. It will come up only when it is collapsed. >Moreover, I never use collapsed threads. So I won't > enjoy the new sorting order? > Hmm do you have a proposal on how it should look like. Ill be happy to look into it.
(In reply to comment #11) > Hmm do you have a proposal on how it should look like. Ill be happy to look > into it. Sort the thread based on the latest timestamp in it. Like you do for colapsed threads.
(In reply to comment #12) > (In reply to comment #11) > > > Hmm do you have a proposal on how it should look like. Ill be happy to look > > into it. > > Sort the thread based on the latest timestamp in it. Like you do for colapsed > threads. > Behdad, Yeah thatz what the end result is. Im just seeing how will the thread will look like. Ill give a lookinto it.
did anybody actually test the thread mode and "hide deleted messages" enabled? it's totally unusbale now as the cursor goes to nowhere it seems. i delete a message and to delete the next message, i have to use the mouse now in the message list pane. thread view and "hide deleted messages" is currently quite unusable to me. why does such stuff has to be committed directly before hard code freeze? couldn't this have been fixed (*and tested*) in the 2.9 cycle?
Created attachment 71996 [details] [review] Improved patch
This should solve both the issue. It determines the node in which delete happens. If root node (earliest message) is deleted, it selects the previous message and the sorting moves the thread some where else and the selection leaves the thread and is present in the current view. If any other node in the thread is deleted, it just selects next message. Andre, can you try this patch?
applied the patch: thread view, hide deleted messages: the thread jump patch makes things better (works fine when *not* deleting the root message), but does not fix it entirely (deleting the root message makes the focus go to the last message and moves the remaining messages of that thread to somewhere else in the message list pane) so i cannot easily delete a second message of that thread after deleting the root message.
andre it is the desired behaviour. We should have a delete selected thread to achieve the result you are looking for.
srini: not at all, wrong. i have a thread with five messages. i want to remove the first one (root) and the second one (=this means: last one in thread view). i hit "del" on the root messages and have to search again for the rest of the thread, because it has gone to somewhere out of sight. this has nothing to do with deleting an entire thread.
Thanks Andre. That's exactly what I tried to say. I still think sorting a thread (collapsed or not) based on the latest timestamp almost solves the problem completely. It will only jump when you remove the latest message in the thread, but that's less of a problem since after deleting the last message your cursor moves out of the thread anyway.
Im not sure the feasibility of this. Ill looking into this.
Im getting some ideas on this (Sorting independent of state). For now, im reverting the patch that I committed to remove the cursor.
*** Bug 356094 has been marked as a duplicate of this bug. ***
bug 356094 is another side effect
Has this been fixed and rebuilt yet, so that Fedora among other distros can get the packages built? I am still experiencing this problem on the FC 6 devlopment series. evolution-2.8.0-4.fc6
Mike, it's been committed to CVS and will be released in Evolution 2.8.1. Srini pointed me to the changes today, and I'll try to get them into Rawhide in the next day or two. Please direct any Fedora-specific questions to the downstream bug report: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205576
Targetting for 2.9. Cant fix in 2.8.x
Yep! done. Now thread sorting is based on time stamp of the latest message. Just committed that to svn.
This was gmail-like sorting from 2.11.5, right? (Posting the commited patch and it's revision number would be helpful now :o) ) So I guess this one can be closed as FIXED?
"gmail like sorting" was introduced since rev 33553 http://svn.gnome.org/viewcvs/evolution?view=revision&revision=33553