GNOME Bugzilla – Bug 677862
Delete of multiple messages can keep cursor out of view
Last modified: 2015-10-08 06:41:57 UTC
(vaguely related to Bug 614896) Case: There's a series of tiresome mailing list threads I want no part of. They are dispersed amongst my folder for the mailing list, so I want to delete each whole thread as I determine its fate, one-by-one. - Collapse all threads (Shift+Ctrl+B) - Click on thread of annoyance and futility (click) - Select all messages in thread of annoyance and futility (Ctrl+H) - Hit Delete Expected behavior: - *IF* I have newest emails on the bottom of the message pane: Focus moves to the next newest group or single message in the message list pane - to the message that had immediately followed the message I last deleted, AND the pane keeps that focused message in view. - *IF* I have newest emails set to the top of the message pane: Focus moves to the next newest group or single message in the message list pane - to the message that had immediately followed the message I last deleted, AND the pane keeps that focused message in view. Actual behavior: - I believe the next newest message wrt the deleted group in the message pane is focused, but the view always scrolls down to the bottom of the pane. This necessitates scrolling way back up (or down) to where they were to get back which can be quite tedious.
Case #2: I select 10 single messages dispersed inside of a folder in the messages pane. - Shift-click on 10 different messages in the pane, potentially scrolling through the list to make selections. - Hit Delete Expected behavior: - With respect to *the very last message I clicked on*, the next newest message should be focused and the pane should keep that focused message in view. Actual behavior: - I believe the next newest message wrt the most-recently selected message in the deleted set of messages in the message pane is focused, but the view always scrolls down to the bottom of the pane. This necessitates scrolling way back up (or down) to where they were to get back which can be quite tedious.
I think this scrolls-out-of-view behaviour had been fixed meanwhile, I recall a bug where the problem was a fight between the idle and timeout callbacks, both influencing which message to scroll to, where also the collapsed threads had its influence on this. I'd appreciate if you could retest in 3.16.x and report back whether that change helped in your use case as well.
Downstream bug report reports the same from ore recent version: https://bugzilla.redhat.com/show_bug.cgi?id=1254852 Description of problem: Selecting multiple messages and deleting them leaves the cursor outside of the viewport; moving the cursor using the keyboard snaps the viewport to the cursor. Version-Release number of selected component (if applicable): evolution-3.17.4-2.fc23.x86_64 evolution-3.16.5-1.fc22.x86_64 (and every version I've tried in 22) How reproducible: 100% if CPU is not loaded. Steps to Reproduce: 1. Select multiple messages (more than fit in the list view window). I use threaded-mode, but it is not clear that is a requirement for the bug. 2. Delete the messages. Actual results: Messages deleted, cursor is on next message after deleted ones, but is not visible in message list (nor is the message subject). Moving the cursor with the arrow keys scrolls the list such that it is visible. Expected results: Messages delete, cursor is on next message after deleted ones, with message list scrolled such that the cursor (highlighted message) is visible. Additional info: This appears to be a race condition, either in sending or processing events relating to the message list. If the CPU is unloaded, this is 100% reproducible. If I have a background compile going that makes heavy use of all cores, this is much less reproducible -- I suspect it can still happen, but I've not been able to do so.
Created attachment 309759 [details] [review] proposed evo patch for evolution; I tried to reproduce this, but no luck here. As it seems like a timing issue, it's possible my machine does things differently due to it. I think I know the place where the fight can be, which tries to address this patch. Could you give it a try, please? As you are able to reproduce the issue more easily, it'll be helpful. To make things easier, I made a test build for Fedora 22 here [1] (it's currently building). Just install it, restart evolution, and try to reproduce with it. I'll appreciate a feedback on it. Thanks in advance. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10767317
Hi Milan, Unfortunately I haven't used Evolution in years and I don't even know what system I was using when I filed this bug. :( My account is quite large and would take some time to sync.... so I don't know that I can be very helpful in reproducing anymore.
Just installed and tried the koji package -- unfortunately, it does not change the behaviour, the list does not scroll such that the cursor/highlighted message is visible.
Máirín: that's okay, thanks for the response. Dave: Thanks for the testing. As the change didn't do anything wrong (at least not noticed) and it seems correct to me, I committed it as commit d6f926d for evolution 3.17.92+. Maybe I do something wrong. Could you describe your folder settings (the sort options, wide or classic view, threaded or flat view (I believe it's the threaded view - Group By Thread), are there any threads collapsed above the selection; and describe your steps, what you press on the keyboard, what you do with the mouse, how you call the function, please? There can be a difference between calling delete by a keyboard shortcut, by the menu shortcut or by context menu or menu being accessed exclusively by the mouse. The more details the better. I certainly miss something here, as I cannot reproduce it. Thanks in advance.
Hmm, let's see what I can brain-dump here. Machine is a i5-4570 3.2GHz, 16GB of memory. I'm running Fedora 22 on the hardware, and Fedora 23 in a VM (boxes). The problem occurs in both environments. IMAP server, many folders (more than 50, less than 100, call it ~80) Classic preview, threaded view (group-by-thread), no threads collapsed, sorted by message date ascending. Process is click on a message in the list. Scroll down with mouse wheel until I find a thread I'm interested in (at this point I'll be a few screenfulls away from the initial message). Shift-click on the message before the interesting one to hightlight from the last one. Press <ctrl-D> to delete. The number of messages in the folder does not seem to matter much -- I usually have low to mid thousands of messages, but just reproduced with 124 messages in a folder. Sort order also doesn't matter -- that test used the default sort order (I created a folder for the test). Grouped by thread, all expanded. (Group by thread doesn't matter, just reproduced with it turned off.) Ah, just may have found a difference -- using <ctrl-D> or clicking on the trash can shows the problem, using <DEL> does not. Please let me know if I can get you more information.
Oh, this was on 3.17.91 on F23.
Interesting. I cannot reproduce this with my main machine, Fedora 21, gtk3-3.16.6-1.fc22.x86_64, but using Fedora 23 or rawhide, with gtk3-3.17.8 I get the same behavior as you.
Created attachment 311384 [details] [review] evo patch for evolution; This helped me. It uses changes from the previous patch. There was a fight between scrolls, I only do not know why not on my main machine, but that doesn't matter that much, the important thing is that I was able to reproduce this. A test build with the patch included for Fedora 23 is building here [1]. Note it's done in a side tag (f23-gnome), because other dependent packages are in that tag as well. That means you might want to download more packages directly from koji, not only evolution (definitely at least evolution-data-server). [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=11095677
Created commit 64e604a in evo master (3.19.1+) Created commit 00cf82a in evo gnome-3-18 (3.18.1+)
Finally got my Fedora 23 VM working again, and can confirm what you already know -- this is fixed in evolution-3.18.0-1.fc23. Thanks for fixing this!
Nice, though the fix landed for 3.18.1, not 3.18.0, so you still do not have it and that it "works fine" for you can be due to the virtual machine lag and such, the thing it worked for me on my main machine too :)