Drag and drop Gtk bugs

While working in FlameRobin I often run into DnD bug that locks up the screen completely. Something takes over the mouse input (it’s called grab) and the only way is to kill FR. It happen often when DnD is enabled, but also sometimes when it is not.

Looks like we aren’t the only ones affected by it. Here are some examples of Evolution team, having the same problem:

http://thomas.apestaart.org/log/?p=502

http://bugzilla.gnome.org/show_bug.cgi?id=365258
http://bugzilla.gnome.org/show_bug.cgi?id=368233

Here’s one idea of a fix:

gtkhtml.c:
static gint
idle_handler (gpointer data)
{
    GtkHTML *html;
    HTMLEngine *engine;

+   GDK_THREADS_ENTER ();

...

+   GDK_THREADS_LEAVE ();

    return FALSE;
}

idle_handler() was missing surrounding GDK_THREADS_ENTER / _LEAVE calls. Due to
this, idle_handler returned and left the global mutex locked, however it should
have been unlocked because idle_handler was called from the idle loop. As the
>mutex was locked, when GTK+ tried to acquire the lock again the thread got
locked (as seen on the previous stack trace).

I just have no idea, where in wxWidgets source do we need to insert those guards. Also, here’s another report:

http://bugzilla.gnome.org/show_bug.cgi?id=351672

Here’s interesting comment from that page:

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.

It seems vanilla Evolution has fixed it now, although some distro-patched versions still exhibit the problem.

Tweet to @mbabuskov Milan Babuškov, 2008-02-11