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 Tweet Milan Babuškov, 2008-02-11