GNOME Bugzilla – Bug 446659
Message view can scroll away after message deletion
Last modified: 2015-02-14 18:12:09 UTC
Please describe the problem: When deleting a message from a message list, the message list selects the next mail message if one exists, or the previous one if the last message was deleted. With IMAP folders, if the message to be selected next was deleted but still visible in the message list (because the network is slow and the delete action has not completed yet), then a deleted message is being "selected". When such a deleted message is being selected, the message entry in the list is not highlighted only has the selection rectangle and the message preview doesn't update, showing still the content of the last message. This is all counter-intuitive. Steps to reproduce: 1. Use an IMAP folder with a slow connection or with very large messages (more then a few MBs). Make sure the bottom of the message list contains two messages that you can delete. 2. go to the last message in the list and hit delete two times quickly Actual results: The last two messages are marked as deleted but are still visible. Evolution tries to select the next message after the penultimate message in the list, and selects a message that is already deleted. Expected results: Evolution should make an effort to try to select a message that is not deleted - i.e. - scan down the list and select the first message that is not deleted, and if none found scan up the list and select the first message that is not deleted, and if none found - disable the selection and clear the preview pane. Does this happen every time? Yes Other information:
I'm not sure if I got the issue. I tried to reproduce it on 2.25.90 and I do not see there any special issue (maybe my user-point-of-view is broken). I run evolution, during the initial fetch everything is "slower", thus I can go to a folder, say 5 messages above the last, and then hit 5 times DEL key. After this I stay on message before the last. All of them are strikeout, which indicates they are deleted. When all pending actions are done, the messages state is sent to the server and view is updated, and I see my cursor on the last not-deleted message, which is shown in a preview pane too. Doing this in a way you suggest it will be strange for those whom have unchecked View->Hide deleted messages. What do you think?
The problem is that until the message list synchronizes, the "currently selected message" is a deleted message. when the network sync is not imediate (and it is rarely so), then it would make more sense to select the next undeleted message - even if it is above the cursor, so that the user can continue to work uninterrupted without waiting for the sync to complete. i'm not sure how "hide deleted messages" factors into it.
(In reply to comment #2) > i'm not sure how "hide deleted messages" factors into it. When you have "Hide deleted messages" unchecked, you always see deleted message in a folder, thus this behaviour can lead to some strangeness. For example, you've deleted last 5 messages, staying on the second undeleted above them, and hitting delete twice will move you not on the first deleted message, but on the last undeleted, above the place where you were, which, I would say, is unexpected. I tend to mark this as a WontFix.
Ok, so I think we have two different behaviors: 1. when "hide deleted messages" is checked, the message list should always select the next undeleted message (regardless of if a message that was deleted is still being seen because the server sync is slow) - or the last undeleted message if there isn't a next undeleted message. 2. When "hide deleted messages" is unchecked, delete goes to the next message regardless. Or - another way would be to simply hide deleted messages as soon as they are deleted when "hide deleted messages" is checked. Sounds quite intuitive I think. I'm not sure why we have to wait for the server sync in order to hide deleted messages.
I'm not sure if this is the same as the original bug, what I'm seeing is: If the message is at the top of the list, then the next message is selected, otherwise Evolution jumps to some random point in my inbox. Theres a video of the behaviour I'm seeing here http://innergeek.aircooled.info/wp-content/uploads/2010/08/out.ogv
> The last two messages are marked as deleted but are still visible. Evolution > tries to select the next message after the penultimate message in the list, > and selects a message that is already deleted. This is still reproducible with IMAP in 3.2.3, however it is only shown for less than a second. Tested with GMail.
I'm pretty sure this is still an issue in 3.6.x. We just got a downstream bug report about a similar thing, when deleting more than one message, which I believe is what Will sees (the video is, of course, gone since the time of 2010). Let's try to deal with both things in once, they are close related. Downstream bug report link: https://bugzilla.redhat.com/show_bug.cgi?id=923120 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.
It's possible the downstream bug report is exhibiting a regression after changes from bug #645476, which landed for 3.6.4.
I can confirm this as of 3.6.4. Description of problem: 1. Highlight several messages from the top down, by clicking the top message, and using shift+arrow key to select multiple. 2. Hit the Delete key. 3. The current message is now n messages down from where it "should" be, where n is the number of messages deleted, instead of on the next undeleted message. Expected behavior: The current message should be the next undeleted message, not some seemingly arbitrary number of messages further down the list. Reproducible: Always.
This got fixed in 3.10. Closing as OBSOLETE.
*** Bug 706782 has been marked as a duplicate of this bug. ***
As indicated in bug #706008 comment #23, this is not fixed in 3.10.x, thus I'm reopening this.
Thanks a lot Milan, I can help with testing if possible since I use evolution all the time and can reproduce this in a reliable way :/
Could anybody try a fix from bug #724854 comment #2 please? If it'll work, then we can mark this as a duplicate of that bug report.
It is still the same :(
(In reply to comment #15) > It is still the same :( Is it? Could you guide me, please? Things like sort options, thread being deleted and what you get instead of what you expect will help, the same as any detail on the issue, cursor positioning and so on.
For example I am just seeing it now while reading my mails from all the day: 1. I am in my main inbox folder, and I have (now) ~32 unread mails. 2. I select first unread mail. 3. I remove it pressing Ctrl+D and go to next mail, I do the same and, suddenly, the list jumps to some unrelated email that is placed much later (at the button) of the list) Not sure if it helps :/
OK. It sounds to me that what you see is caused by the sorting of a view, and thread sorting by its latest message date. Consider this view (numbers is a month-day pair when it was received), with sorting by Date): A 01-01 B 01-02 C 01-03 D 01-01 01-01 01-02 01-04 <cursor here> 01-02 The thread D is after thread C, because its latest message date is 01-04. And now, if you decide to delete that 01-04 message, then evolution moves cursor to the next 01-02 message, but also resorts the view, which moves the thread D before thread C, because the latest message in it is now at 01-02. The view changes to: A 01-01 B 01-02 D 01-01 01-01 01-02 01-02 <cursor here> C 01-03 It doesn't jump that drastically in this example, but it shows the principle which may cause this issue - whole thread movement. If it's this, then the fix might be to not apply sorting on change which was done in UI, though this is not that easily applicable, because the UI receives real change notification "asynchronously", through a "changed" signal notification of the selected folder.
In some cases it's maybe caused by threading, in others, it also does the same even if mails are the only ones from a thread. In general, when the list "jumps", I need to scroll up/down to find the mail that is selected in the list (the one that I am reading after Ctrl+D)
Interestingly, it was shown to me just yesterday a case which you see. What I've seen: a) message list sorted by Date descending, all threads collapsed b) pick an alone message (no submessages), with scrolled view not at the bottom, but further at the top c) delete the message What happens is that the selected message is the right one, the next from the deleted (at least as I see it), but the view itself (scrollbar position) jumps to the bottom, leaving message list view without that selected message shown. I wasn't able to reproduce it on another machine, but I will keep trying soon.
Created attachment 270605 [details] Video.webm Video showing the issue
Right, it's what I described (or tried to describe) in comment #20.
OK, I found the cause (and changed summary of the bug report to better reflect what was the issue). Long story short: your computer is too quick. :) The problem was that there was a little fighting about scrollbar position. One part requested to show the cursor position after a delay of 260 ms, while another part requested to do the same on idle. It was done in this order. If the idle happened before the timeout, then the issue arose. It was a bit more complicated, because there was also necessary to have collapsed threads, because the timeout request computed table row with all threads expanded, thus the collapse state restore shifted correct line, which led to a request to select the right message, but at the too-bottom position, where it was not anymore. The below change does couple things: - move real cursor/selection restoration to a place where the thread collapse/expand state is properly set, thus the computation of the message's row in the table counts with the right values - do not issue the timeout cursor restoration when it's not needed (like on a folder change notification) - lock only the ETableItem, which is the main cause of the issue The change has also one side-effect, the message list filling is quicker, approximately by 50% (one of my folders has more than 17.7K messages and the whole filling took a bit more than 0.6 second, while it takes a bit more than 0.3 second with the fix). I also tested related changes, like deleting multiple messages, not moving to the cursor when a folder changes and it is not visible, and all of them seem to work properly to me, thus it should be fine. Create commit 8b68023 in evo master (3.11.92+) [1] [1] https://git.gnome.org/browse/evolution/commit/?id=8b68023
Ah, thanks a lot for the investigation. Will wait for 3.12 to test (I can't test 3.11.x right now)
*** Bug 725843 has been marked as a duplicate of this bug. ***
Hrm, a regression reported at bug #731278.
*** Bug 742995 has been marked as a duplicate of this bug. ***