After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673328 - After clicking empty parts of a toolbar/menubar the next mouse click (button release) does not work
After clicking empty parts of a toolbar/menubar the next mouse click (button ...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkToolbar
3.4.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-04-02 01:48 UTC by Volker Sobek (weld)
Modified: 2012-04-05 08:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
x11: Don't ignore button releases after a wmspec move/resize (2.43 KB, patch)
2012-04-04 14:55 UTC, Rui Matos
committed Details | Review

Description Volker Sobek (weld) 2012-04-02 01:48:36 UTC
After clicking on an empty part of a toolbar (to drag the window, for instance), clicking a button in the toolbar doesn't work. It looks/behaves as if the mouse button would not be released. You have to do a second click to actually click the button successfully.

I see this behavior for instance with the toolbars of nautilus (path-bar), evolution and system settings.

Happens with my up-to-date Fedora 17 with
gtk3-3.4.0-1.fc17.x86_64
Comment 1 Volker Sobek (weld) 2012-04-02 01:56:23 UTC
This bug is kind of dangerous in the case of nautilus, where, after clicking an empty part of the path-bar, the next click inside the current folder will behave as if you don't release the mouse button, so the user accidentally can move or mark folders with the rubber band.
Comment 2 Volker Sobek (weld) 2012-04-02 02:27:10 UTC
Edit: also happens when clicking empty parts of a menubar! That explains the seemingly random selections I had seen in gnome-terminal for some time now.
Comment 3 Matthias Clasen 2012-04-03 11:08:52 UTC
I can confirm this; likely fallout from

commit db2eb85e4af9d8f191fe1ade53ec85a94b326c9f
Author: Rui Matos <tiagomatos@gmail.com>
Date:   Wed Feb 1 17:59:23 2012 +0000

    x11: Cancel _NET_WM_MOVERESIZE if we get a matching ButtonRelease
    
 

Rui, can you have a look ?
Comment 4 Matthias Clasen 2012-04-03 11:23:15 UTC
It seems that just moving the handle_wmspec_button_release call to the end of
_gdk_x11_moveresize_handle_event is enough to make the problem go away.
Comment 5 Rui Matos 2012-04-04 14:55:26 UTC
Created attachment 211303 [details] [review]
x11: Don't ignore button releases after a wmspec move/resize

_gdk_x11_moveresize_configure_done() isn't called for wmspec
moves/resizes so we don't have a way to notice when a wmspec
move/resize ends and consequently untrigger the sending of
_NET_WM_MOVERESIZE_CANCEL which results in this message always being
sent on the next button release event. In that case we are marking
that event as handled so it isn't processed further which breaks
button press/release event handling in several widgets.

To fix this we simply allow the normal event handling machinery to run
after sending the _NET_WM_MOVERESIZE_CANCEL message.

--
Yup, I misunderstood how _gdk_x11_moveresize_configure_done() was
being called when I did that code. This patch should fix it.
Comment 6 Matthias Clasen 2012-04-04 22:26:48 UTC
Review of attachment 211303 [details] [review]:

looks ok
Comment 7 Rui Matos 2012-04-05 08:17:43 UTC
Attachment 211303 [details] pushed as 7b0fd63 - x11: Don't ignore button releases after a wmspec move/resize