Bug 41282 – permanent mouse grab after clicking to image

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Stanislav Brabec]

The browser sometimes permanently enters to a mouse grab mode. It happens after clicking to an image inside a web page.

How to reproduce:
Wobble with your mouse quicky and very shortly click to any image on any web page.
Different cursor indicating manipulation with the image appears and stays forever after mouse button release. Browser has mouse grab and it is impossible to leave the application, click anywhere or so.

Does it appear every time:
No it appears only sometimes. It is easily reproducible on slow machines (PDA) and hardly on slower desktop systems.

The problem was reproduced on:
Linux openSUSE 11.3 RC1 x86_64, epiphany-2.30.2 libwebkit-1.2.0 (user agent 531.2)
Linux Angstrom ARM (PXA270, armv5tel), midori-0.2.2, libwebkit-1.1.18 (svnr53071)

Work-around that works on both midori and epiphany: Press Ctrl+L, go to the end of the URL, type any letter, wait for URL completion pop-up. This operation releases mouse grab.

[Stanislav Brabec]

Created attachment 59906 [details]
backtrace of epiphany in the mouse grab (done from text console)

[Stanislav Brabec]

Created attachment 60886 [details]
gdb backtrace at gdk_pointer_grab breakpoint

Backtrace when breakpoint is set to gdk_pointer_grab() and gdb is running on a different display.

With gdb, the race can be easily reproduced: When starting grab, gdk_pointer_grab is called twice. If you ensure, that the second breakpoint is executed after mouse button release, the problem occurs.

How to reproduce:

1. Run gdb on a second machine and set breakpoint to gdk_pointer_grab
2. Shortly drag any image or link and release.
3. In gdb do:
bt
cont
bt
cont

Actual result: browser runs, drag is finished, but the browser still has a mouse grab.

[Stanislav Brabec]

After a deeper analysis it looks like a gtk+ bug. Reporting as https://bugzilla.gnome.org/show_bug.cgi?id=623865

[Stanislav Brabec]

The bug is confirmed as an GTK+ problem, but there is an issue that may be addressed in webkit:

DragClient::startDrag() may be interested in the system event details that triggered the drag. It could affect the toolkit behavior.

Constructing of an artificial event instead of use operating system event is just a work-around.

[Martin Robinson]

Seems this was a GTK+ issue.