GNOME Bugzilla – Bug 351672
Dragging imap message when another is copying locks X
Last modified: 2008-08-07 16:20:24 UTC
Please describe the problem: If I drag one message from an imap folder to another and, while it is still coying, start dragging the one below it, the application will lock my mouse cursor into a mode and never return. (i.e. the second drag operation never completes). This mode prevents me from clicking on any other application or from using the keyboard. The only solution I've found is hitting Ctrl-Alt-F1 to switch to a text terminal, logging in, and typing "killall evolution." (No -9 is necessary; the app is not locked, only my X input state.) Aside from any imap issues, it seems to me that locking the user input in this way is a bad idea. Other apps (for example, Firefox) don't do this, but instead if you drag the item to an invalid space (outside the app window, for example) it just cancels the operation. Steps to reproduce: Best done with a slow imap server, but even without reproducing the imap bug the input locking should be obvious since it does that every time by design. Actual results: Expected results: Does this happen every time? Other information:
which distro is this? which evo version is this exactly?
I've run into this bug on both the 2.5 and the 2.6 series, on several distributions (Fedora and Ubuntu that I can think of offhand) and on a number of different machines over the last year or two. My current setup is Ubuntu 6.06 with Evolution 2.6.1. I've been using the same mail server this whole time (just a standard RHEL4 install with Postfix and Dovecot for the imap) so I suspect I'm seeing it more often than others due to some peculiarity in the setup there. (Maybe just that it's slow.)
I also experience this bug at least once every other day or so using evolution (both evolution-2.2 2.2.3 on Fedora Core 4 and evolution-2.6 2.6.1 on Ubuntu 6.06) with IMAP mail. I had not figured out how to reproduce it, but Adam's synopsis seems to be correct. I also have to quit to a text console and killall evolution. In case its not clear from his description, what happens is that you start to drag the mail to a folder, the mouse cursor changes to the drag icon and then will never change back, preventing you from doing anything in X. I will attach a backtrace I just took from the text console while my cursor was stuck in Drag mode.
Created attachment 72622 [details] backtrace of evolution while cursor locked in drag mode Backtrace of all evolution threads while cursor stuck in drag mode.
I have experienced with as well, with exactly the same versions of Evo on exactly the same distros as Gavin. I would call this one confirmed, although I have not tested it with 2.8 in Edgy.
I looked into this further -- its driving me crazy. The bug occurs when emft_drop_async_done calls gtk_drag_finish while you are in the process of dragging a mail message. Note that this can occur because emft_drop_async_done is called asynchronously at some point *AFTER* you have dropped a message in a folder, thus giving you time to start dragging a different message. AFAICT this gtk_drag_finish call is unneeded because em_folder_tree_enable_drag_and_drop sets GTK_DEST_DEFAULT_ALL, which causes gtk_drag_finish to be called automatically. Removing the emft_drop_async_done gtk_drag_finish call resolves this bug for me. I will attach a gdb session where I set a breakpoint on gtk_drag_finish, attach to a running evolution process, and drag a mail from the message list into a folder while using an IMAP server. It shows 3 breaks, two result from the GTK_DEST_DEFAULT_ALL-related calls and one is from emft_drop_async_done. I am currently running evolution-2.6.1-0ubuntu7 on Ubuntu 6.06 (dapper drake), but this bug exists on every version of evolution I can find, including CVS HEAD. STEPS TO REPRODUCE: 1) set up an imap account, preferably to a "slow" server 2) view one of the imap folders 3) drag a message from the message list and drop it on a different imap folder 4) *AS FAST AS POSSBILE* start dragging a different message from the message list. You have gone too slow if the original message (step 3) disappears from the message list before you start dragging the second message
Created attachment 78664 [details] gdb session showing gtk_drag_finish calls
Hi all! I wish to confirm that this bug still exists in 2.10.1 in Ubuntu Feisty. It is painful, honestly. tarek : )
another metoo. A better workaround that I discovered this week is that you can start another evolution process from a console, which allows you to pick up where you left off and at least expunge your moves/deletions, instead of having to redo them after killing evo.
I don't think I made it clear in comment #6, but the attached 1-line patch fixes this for me. I haven't noticed any adverse affects from it since last December. Someone with more gtk drag-and-drop knowledge than me should double-check I'm not missing something.
Created attachment 91115 [details] [review] Patch described in comment #6
Gavin, the issue could be little different. The gtk_drag_finish gets called in a non-main (gui) thread. Im not sure, about the removal of that call. Matthew, any idea?
Maybe we just need to throw a gdk_threads_enter()/leave() guard around it. I'll take a closer look...
I think Gavin has right. Based on the documentation for signals "drag-drop" and "drag-data-received", gtk_drag_finish is supposed to be called in one of this signal handlers to let the source know that the drop is done. Evolution do this too late, from my point of view, so it breaks this rule and when dragging next message the call for gtk_drag_finish breaks UI. Also as Gavin proved by callstack, with GTK_DEST_DEFAULT_ALL used with gtk_drag_dest_set, call of gtk_drag_finish is made automatically, in the proper place, and as I tested it a bit, it seems to me that it works in a same way like before Gavin's patch from Comment #11 (but I'm not a gtk guru at all, so I may be wrong). Gavin, if you add a ChangeLog entry to your patch, then I would like to suggest to commit it to trunk.
Created attachment 94580 [details] [review] proposed evolution patch OK, here is a patch with a ChangeLog entry. Since all emft_drop_async_done really does is call gtk_drag_finish I removed it entirely in this version.
Patch looks fine to commit. Only one thing, you've picked up wrong ChangeLog file, there is one in /mail subdirectory, so I moved it there.
Committed to trunk. Committed revision 34135.
I'm still able to experience this problem with evolution-2.12.2-2.fc8 for Fedora 8. I did selected multiple messages at the same time to make sure that the system was slowed down enough for me to DnD another message before it finished with the first batch. This looks like a duplicate of bug 308354 and bug 408471.
*** Bug 308354 has been marked as a duplicate of this bug. ***
*** Bug 408471 has been marked as a duplicate of this bug. ***
Guys, I'm using 2.21.90 from trunk and I tried dragging 100 emails thrice, one after the other to my IMAP folder and I don't see it. I can see that the tasks are queued. Just to know, if it is a distro specific bug, Matt/Milan can you see if it happens for you on Fedora/trunk?
Does the hang happen on trunk if you refile messages two or three at a time instead of one at a time? Does it matter if you select discontiguous messages from the folder list?
Oh, I dragged 100 at a time. (but they were contiguous).
evolution-2.12.2-2.fc8 contains a patch (evolution-2.8.1-kill-ethread.patch) that basically restores the gtk_drag_finish call that the fix in revision 34135 removed. They do it in a new function, emft_drop_async__done (that's two _'s before done). AFAICT plain-vanilla evolution-2.12.1.tar.bz2 should not have this problem.
That patch has been removed in evolution-2.12.3-1.fc8.
I'm still able to reproduce this problem in evolution-2.12.3-1.fc8 with contiguous selects.
Oops, it's back in actual trunk too, only the name is emft_drop_async__done (two underscores at the end instead of one). Same code is in F8 version too.
Ah crap, probably introduced while merging changes into my "kill-ethread" checkout. That stuff was committed in revision 34730.
Yeah, here's the revision where my patch puts the old logic right back in. http://svn.gnome.org/viewvc/evolution/trunk/mail/em-folder-tree.c?r1=34730&r2=34729&pathrev=34730
Re-fixed in revision 35124. Milan, you want to handle this for Fedora 8?
Sure, building evolution-2.12.3-2.fc8 right now, will push to updates-testing tomorrow morning (CET).
I did it today, finally, so package for f8 is in updates-testing now. If you wish you can try, Christopher.
I tested evolution-2.12.3-3.fc8, and I can no longer reproduce this bug. Yay!
*** Bug 374809 has been marked as a duplicate of this bug. ***