GNOME Bugzilla – Bug 82128
GtkButton doesn't get release when pointer grab in effect
Last modified: 2015-08-08 13:12:15 UTC
Buttons in the logout dialog do not disarm properly when the user starts a click but then has a change of heart. It's easier to see than to describe. Try the following: 1. Select "Log out" from some panel menu. 2. In the "Really log out?" dialog, move the mouse pointer inside the "Cancel" button. 3. Press mouse button 1, but do not release yet. Notice that the "Cancel" button appears armed (pressed in). This is correct. 4. While keeping mouse button 1 down, move the mouse pointer outside of the "Cancel" button. Notice that the "Cancel" button appears disarmed (not pressed in). This is correct. 5. While the mouse pointer is outside of the "Cancel" button, release mouse button 1. 6. Move the mouse pointer back inside the "Cancel" button. Do not press mouse button 1. Observe that the "Cancel" button appears armed (pressed in). This is incorrect. My guess is that someone's playing tricks with X events or something like that.
Oops, why did I file this as a gdm bug? This is clearly a gnome-session bug. My bad.
Owen: David Kennedy (tinytoad) on irc.gnome.org#bugs said that this bug reminded him of a gtk bug he read recently; He said he thinks that this may be a gtk bug and that you would know. Is it? I can duplicate on a Mandrake 9 system (which uses gnome-session-2.0.5). So, changing version from 1.5.x to 2.0.x. Also, changing severity to trivial (perhaps it's ugly and annoying, but it doesn't seem to be notticed by very many) and adding bugsquad keyword.
The problem here is that while there is a pointer grab in effect (gdk_pointer_grab()) the normal implicit grab that happens on mouse presses doesn't happen, so the button doesn't get the button release. It's one of a class of bugs that occur because of this flaw in the X protocol; there are things that could be done to fix this in GDK... basically emulate the implicit grab ... but would definitely be Hard. Feel free to assign to GTK+, but I doubt it will be fixed in the forseeable future.
Moving to gtk+, as per Owen's comment.
Please test this again with the latest in the gtk-2-4 or HEAD branches; I think it is fixed there.
It's not fixed .... this is about pointer grabs killing implicit grabs, not gtk_grab_add() shadowing events.
I think this is affecting Totem. Try dragging the progress slider, but move your mouse to the status bar (make sure you don't leave the window). Release the mouse pointer, and observe that as you move the mouse, the progress slider carries on moving! If it's not this bug, I'll open another.
The original bug was fixed, I checked it with gtk-2.14.4. Comment#7 is not this bug, so I think the bug can be closed. About Comment#7, I think it may not be a bug. All of the progress bar can be moved while dragging outside it and it is good for the users as it is hard to keep the dragging so vertical or horizontal.