GNOME Bugzilla – Bug 332765
auto-selection of the first message is annoying
Last modified: 2013-09-13 00:48:35 UTC
if I delete and expunge the last message in the message-list, the message-list gets scrolled to the very top and the first message is auto-selected. this is very annoying because new mail always appears at the end of my message-list when it arrives. This means I have to scroll again (not a huge catastrophe, sure, but annoying because I can't see the subjects of the new mail until I scroll) the old behaviour was such that if the selected message was deleted/expunged, it wouldn't auto-force-select the first message and so it didn't scroll back to the top. This was much preferred... One possible fix to this if a emssage has to be selected would be to select the closest message to the one that had been deleted/expunged-while-selected. If there's a message afterward, select it - if not, select the message previous to the one expunge? Other information:
*** Bug 343887 has been marked as a duplicate of this bug. ***
This has really been bugging me as well...
The behaviour that I see with 2.8.0 is different: when a selected message is deleted and removed from the list, the selection disappears instead of moving to the next message, as it did in 2.6. The scrolling position does not change. It's still annoying, as I can't easily browse my mail folders anymore using the keyboard alone. After I hit Delete and try to select the next message with the Down arrow key, the selection moves to the beginning of the list.
Mikhail: I can't reproduce it with 2.8.0. It happened with 2.6 for me but now it's working (Ubuntu Edgy Beta). However, if I move the last (bottom-most) message to another folder, no selection is made. Therefore, when I switch to another folder and then switch back to the original folder, the view is scrolled way back up to the very top. It works correctly when moving not the bottom-most message.
Sorry for comment-spamming but I have to make an addition to my previous comment: Mikhail: I can reproduce what you are saying but only when selecting multiple consequent bottom-most messages. Here some example configurations showing the four bottom-most messages with "-----" representing a non-selected message and "*****" a selected one: These are working as expected: ----- ***** ***** ----- and ----- ----- ----- ***** and ----- ***** ----- ***** NOT working (no selection after deleting the selection): ----- ----- ***** ***** or ----- ***** ***** ***** etc.
I have the View setting enabled to hide deleted messages. Oddly, when I select _multiple_ messages and delete them, the selection does move to the next message in the list! I observe this in the local Inbox folder, so no IMAP involved.
Do you have "Group by threads" enabled? Because I had not and the behavior was as described above. Now I have turned it on and I have the same behavior as you described. After deleting the messages it seems to select the first not-deleted message if founds, starting searching from the message that was selected last (using ctrl+click, shift-click or shift-<down-arrow>). In consequence, if the last selected message is the bottom-most one, it doesn't work again.
(In reply to comment #7) > Do you have "Group by threads" enabled? > Because I had not and the behavior was as described above. Now I have turned it > on and I have the same behavior as you described. Yes I confirm that.
This is still buggy with Evolution 2.9.5 (on Ubuntu feisty). Having the bottom-most message selected and hitting the "junk" button (and I receive a lot of junk) makes the selected message disappear (it's moved to the junk folder) leaving my current view without a valid selection. This leads to the behaviour described above: the view is scrolled to the very top the next time I reload the view or use cursor keys to navigate. As we already have found out that some cases/combinations are already covered, I would appreciate it if a dev could point me to the relevant places in the source code. That way I could see what is already done (and HOW it is done, as I'm unfamiliar with evolution code atm) and possibly derive a more general implementation that covers _all_ cases from it.
Created attachment 84424 [details] [review] bugfix This patch should fix the problem by not only searching for undeleted messages _below_ the currently selected one but also _above_ if the former fails. Thus, if deleting the bottom-most message, the now bottom-most will be selected instead of not having any selection at all.
Christof, the patch looks fine. It fixes the problem of not selecting the right mails on deletion. I tried another scenario. Went to junk folder. Selected the last message and chose NOT JUNK. It lost the selection as this. Im sure that you can address this too. Thanks for this awesome patch.
Created attachment 84654 [details] [review] bugfix revision 2 This gets a little bit complicated now. The original function was called find_next_undeleted but was also called when dealing with junk or trash folders. Since it's just a static function it can be renamed safely. I called it find_next_selectable because this is what it actually should do. The caller of the function later selects the entry this function returned. Now comes the complicated part: What we are looking after in this function depends on the folder type we are currently in. When we're in the trash folder we are _not_ looking for undeleted messages but for deleted ones. When in a junk folder, we look for junk mail but not deleted ones in the case of hidedeleted. In order to deal with all the cases, I've written a helper function is_node_selectable. I tried to write some comments that should make clear what the patch does in detail. While it works for me so far, I'm not sure if this could be implemented in a more concise way and if it does not introduce some bugs because of evolution being a multithreaded application. Please check if I access something (namely ml->folder->folder_flags) that could cause problems.
Hey Christof, I dont see any problems, as the current code too does that. The patch works awesomely great for me. I dont see any straight forward issues. Just commit to Stable and Head branches.
Great. I'm not sure about what you meant by saying "Just commit to Stable and Head branches." Is there something I can do from here on? Or was it directed to some evolution developer?
Christof: Do you have permission to commit to GNOME SVN? If not, Srini should do this...
I will commit this along with release.
Committed to trunk (revision 33394) and the gnome-2-18 branch (revision 33395) with some minor refactoring to fix compiler warnings introduced by this patch (flags used uninitialized, unused variable, etc.). Wanted to make sure this gets into 2.10.1.