[GTK] Drag gesture can take mouse grab indefinitely

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Grant Gayed]

- using WebKit 1.1.16 built from source on Ubuntu 9.10

- run the GtkLauncher app and navigate to a page that shows a static image (eg.- the banner at the top of http://www.slis.indiana.edu/faculty/hrosenba/www/Demo/Demo5.html )
- click quickly and repeatedly on the image while moving the mouse a little bit, and you'll soon (within a few seconds) get into a state where WebKitGTK has taken mouse grab and there's no way to get it to let go
- additionally, when this happens the following is written to stdout:

(GtkLauncher:22437): Gdk-CRITICAL **: gdk_window_get_events: assertion `GDK_IS_WINDOW (window)' failed

(GtkLauncher:22437): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(GtkLauncher:22437): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

[Grant Gayed]

To clarify, I equated repeated clicking with the drag gesture because when the problem occurs the cursor is left as the drag hand with '+', so I assume that the problem trigger is that a drag is being initiated while clicking and moving the mouse.

[David Weinehall]

I've experienced this too, several times.  Seriously annoying bug.  FWIW evolution used to have this kind of bug a long time ago; if you need help to figure out what's wrong, maybe some evolution developer might have some insight (that might of course a totally unrelated issue though).

[Jeremy Nickurak]

Confirming present in 1.1.23. Locks up not just the embedding browser in question, but the entire desktop as a result, until epiphany is manually killed.

[Grant Gayed]

Increasing severity to critical because this is easily hit, and locks the whole desktop.  Surely this puts it among the most significant problems.

[Jeremy Nickurak]

As a workaround, in epiphany anyways I seem to be able to usually get out of this by opening a gtk menu, as in alt+F to open the file menu.

[Gauvain Pocentek]

Hi,

The bug is still present in webkit 1.2.0.

I've seen this on a slow machine, and the problem appears on all the system DND (not the JS ones). If the release event is received before the drag icon (the one that follows the cursor) is realized, then the lock happens.

If I understand the code correctly, a workaround is implemented in firefox for this. It uses a GtkInvisible that is realized immediatly after creation, and dnd events are tracked on this widget (nsDragService constructor in widget/src/gtk2/nsDragService.cpp).

HTH.

[Martin Robinson]

*** Bug 27840 has been marked as a duplicate of this bug. ***

[Martin Robinson]

Created attachment 57806 [details]
Patch

[Xan Lopez]

Comment on attachment 57806 [details]
Patch

Woot.

[Martin Robinson]

Committed r60632: <http://trac.webkit.org/changeset/60632>

[WebKit Review Bot]

http://trac.webkit.org/changeset/60632 might have broken GTK Linux 64-bit Release
The following changes are on the blame list:
http://trac.webkit.org/changeset/60632
http://trac.webkit.org/changeset/60633
http://trac.webkit.org/changeset/60634
http://trac.webkit.org/changeset/60635
http://trac.webkit.org/changeset/60636

[Martin Robinson]

Created attachment 57917 [details]
Start the drag with the current GTK+ event

[Martin Robinson]

Because of recent changes to the GTK+ event sender it is now possible to start the drag with the current GTK+ event. I've attached a patch using this method.

[Xan Lopez]

Comment on attachment 57917 [details]
Start the drag with the current GTK+ event

Oh gods of GTK+, accept this offer.

[Martin Robinson]

Committed r60709: <http://trac.webkit.org/changeset/60709>

[WebKit Review Bot]

http://trac.webkit.org/changeset/60709 might have broken GTK Linux 32-bit Release
The following changes are on the blame list:
http://trac.webkit.org/changeset/60712
http://trac.webkit.org/changeset/60713
http://trac.webkit.org/changeset/60709
http://trac.webkit.org/changeset/60710
http://trac.webkit.org/changeset/60711