Description of problem: In a view with deleting messages hidden, when deleting more than one message, by selecting more than one message and leaving the tree cursor at any position other than the very first selected message, the cursor ends up at the same numerical index rather than being adjusted for the removed messages. This happens irrespective of sorting order. Version-Release number of selected component (if applicable): evolution-3.6.4-2.fc18.x86_64 How reproducible: All the time, starting yesterday. Steps to Reproduce: 1.Make sure View->Show deleted messages is disabled 2.In a folder with lots of messages, click on the top message 3.Now shift-click on the second message or, equivalently, press Shift+DownArrow 4.Delete those messages (e.g. Ctrl+D) 5.Note new position of cursor, i.e. which message remains selected. Actual results: The cursor is positioned at the same location as before the deletion (the second message). Expected results: The cursor position should have been adjusted to take account of the deleted messages, and the first message should have been the current one. Note that if the cursor is placed at the expected position prior to deleting messages, all appears normal. For example: click on the second message, then shift-click on the first message, and delete them. The cursor is now on the first message as expected -- but only because the cursor was already in the correct position. Additional info: This seems to be a distinct problem from bug #789984 (in which the correct message is selected but the scroll position is incorrect) which I have *not* seen.
Thanks for a bug report. I guess the difference between this and the bug #789984 is the multi-select versus single-select. The observation with numerical index is very good, because it's exactly what the message list does. Let's deal with this upstream, at [1]. [1] https://bugzilla.gnome.org/show_bug.cgi?id=446659
*** Bug 927235 has been marked as a duplicate of this bug. ***
Milan, I don't know if it's good to add it into some old bug. And if I understand the bug well it's different problem. > How reproducible: > All the time, starting yesterday. This means in my environment that it's since evolution upgrade to 3.6.4. It was working properly in evolution 3.6.3.
Hmm, in that case, probably a fallout from [1] (yet another). [1] https://bugzilla.gnome.org/show_bug.cgi?id=645476
This is back again. evolution-3.10.4-1.fc20.x86_64
Right, I reopened the upstream bug report few days ago. Let's stick with it, rather than duplicate the bugzilla-work in two bugzillas.