- 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
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.
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).
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.
Increasing severity to critical because this is easily hit, and locks the whole desktop. Surely this puts it among the most significant problems.
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.
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.
*** Bug 27840 has been marked as a duplicate of this bug. ***
Created attachment 57806 [details] Patch
Comment on attachment 57806 [details] Patch Woot.
Committed r60632: <http://trac.webkit.org/changeset/60632>
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
Created attachment 57917 [details] Start the drag with the current GTK+ event
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.
Comment on attachment 57917 [details] Start the drag with the current GTK+ event Oh gods of GTK+, accept this offer.
Committed r60709: <http://trac.webkit.org/changeset/60709>
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