GNOME Bugzilla – Bug 623213
permanent mouse grab after clicking to image
Last modified: 2010-07-23 21:00:55 UTC
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 not easily reproducible on desktop systems, but if I want, I am able to reproduce it in several minutes on my machine (Athlon 64 3000+, NVidia GeForce FX5200). The problem was reproduced on: Linux openSUSE 11.3 RC1 x86_64, epiphany-2.30.2 libwebkit-1.2.0 (user agent 531.2) Work-around: Press Ctrl+L, go to the end of the URL, type any letter, wait for URL completion pop-up. This operation releases mouse grab. Note: Epiphany is not the only browser affected by this problem. That is why I reported this bug also as https://bugs.webkit.org/show_bug.cgi?id=41282 You can find a backtrace there.
It looks like a gtk+ bug: Reporting as bug 623865.
Strictly speaking, this is a Webkit bug. It doesn't pass a valid timestamp to gtk_drag_begin(), even though it has one since the call is happening from a motion-event handler. Webkit should use the timestamp from that motion event to initiate the drag. In the meantime, GTK+ now tries to get the current event's time from within gtk_drag_begin() if it is passed GDK_CURRENT_TIME, but Webkit should be fixed too.
Too bad we didn't get this comment months ago! The bug has been fixed for a while in WebKit anyway, but I think it's good that GTK+ does not freak out when given bad data now.
Federico, I do not agree. This is a clean GTK+ race condition. WebKit developers just strictly followed existing documentation without digging deep into the implementation. Documentation does not tell that event passed to gtk_drag_begin() must be a real event and not a synthetic event using GDK_CURRENT_TIME. Well, however it is not documented, gtk_drag_begin() code even allows to pass event = NULL, and in this case the problem can appear as well. Now it should always work. Maybe it could be documented. Regarding the webkit: Yes, there is a design flaw in the webkit platform independent part: Platform independent part does not pass (or did not pass) triggering platform dependent event to the patform dependent part, so the DragClient::startDrag() does not have this information available. https://bugs.webkit.org/show_bug.cgi?id=41282#c4 I guess we can close this bug, it is surely not an epiphany issue.
I've added this blurb to the documentation for gtk_drag_begin(): * The @event is used to retrieve the timestamp that will be used internally to * grab the pointer. If @event is #NULL, then GDK_CURRENT_TIME will be used. * However, you should try to pass a real event in all cases, since that can be * used by GTK+ to get information about the start position of the drag, for * example if the @event is a GDK_MOTION_NOTIFY. * * Generally there are three cases when you want to start a drag by hand by calling * this function: * * 1. During a button-press-event handler, if you want to start a drag immediately * when the user presses the mouse button. Pass the @event that you have in your * button-press-event handler. * * 2. During a motion-notify-event handler, if you want to start a drag when the mouse * moves past a certain threshold distance after a button-press. Pass the @event that you * have in your motion-notify-event handler. * * 3. During a timeout handler, if you want to start a drag after the mouse * button is held down for some time. Try to save the last event that you got * from the mouse, using gdk_event_copy(), and pass it to this function * (remember to free the event with gdk_event_free() when you are done). If you * can really not pass a real event, pass #NULL instead. *
In my opinion, the race condition should be fixed or gtk_drag_begin() should just fail with a NULL or event with GDK_CURRENT_TIME. I don't believe gtk_drag_begin() should knowingly accept a type of input which may totally freeze the application. At the very least, the documentation should be very clear about the risks ("will freeze the application"). The new documentation condones it without making this clear.
Fix in the bug 623865 already prevents the risk of time disparity freeze that happened in WebKit.