GNOME Bugzilla – Bug 650943
Clicking resize grip causes strange mouse grabbing behavior in xmonad
Last modified: 2011-12-10 02:28:25 UTC
The GtkWindow "has-resize-grip" property has default value TRUE, which makes many windows look ugly with a tiling window manager. The resize grip simply wastes space (covering the window content) with a tiling window manager, since such a window manager automatically resizes windows to fill the available space and stops the resize grip from working. (The WM provides its own methods for manual resizing if necessary, that don't require a grip.) In fact, if I accidentally click the resize grip, it somehow grabs my mouse click and does not return it, i.e. I can still move the mouse around but all of mouse buttons stop working (until I restart X). To be specific, my WM is Xmonad and the GTK3 applications I use are gnome-terminal and evince, but I think this is a general problem with resizable GTK3 windows on tiling WMs. I would like to be able to globally configure the value of the has-resize-grip property somehow, in particular to set it to FALSE on my system.
I'm seeing the exact same behavior (with a very similar setup). With xmonad and gtk3 apps with resize grips, clicking on the grip seems to capture the mouse so that it cannot be used anywhere at all. For what it's worth, I'd also love to have the option to turn this off, for the reasons that Ramana mentioned. Let me know if I can provide any information to help in debugging this. Package versions: gtk3-3.0.10-1.fc15.x86_64 xmonad-0.9.2-7.fc15.x86_64 I hope this is enough information to change the status to NEW. Apologies if I'm mistaken.
It turns out that the appearance of the resize grips is already configurable. I was able to make them go away by adding this to ~/.config/gtk-3.0/gtk.css: * { -GtkWindow-resize-grip-height: 0; -GtkWindow-resize-grip-width: 0; } Hooray for allowing such control/flexibility via CSS! This works around the issue for me, but I'm leaving this open, since the mouse-grabbing behavior is probably still a bug.
Thanks for the workaround!
Thank you for the workaround. This bug is not limited to tiling window managers, FluxBox and PekWM both lose the cursor when the resize grip is selected in gtk+ 3.0.11 on Arch Linux. Seeing as this can critically screw up systems for people who aren't comfortable with switching to a tty to kill the offending applications, I would think this bug should be of a relatively high priority. That said, I'll do anything I can to assist with fixing it.
Hi - here's a little more analysis on what's causing this bug. The problem seems to be the call to _gdk_x11_moveresize_handle_event in gdk/x11/gdkdevicemanager-xi2.c. The call passes an special XI2 XEvent where the type is always GenericEvent, and the real event data is stored in a cookie. However, the code in _gdk_x11_moveresize_handle_event expects a regular XEvent. As a result, the switch on event->xany.type in _gdk_x11_moveresize_handle_event always sees a GenericEvent, so the mouse move and mouse releases end up being ignored, and the pointer grab never gets released. I tried to write a reasonable patch for this, but unfortunately, the assumption that _gdk_x11_moveresize_handle_event gets a regular XEvent is pretty deeply ingrained into gdk/x11/gdkwindow-x11.c. For example, it sometimes stores a copy of the event in mv_resize->moveresize_pending_event, but the code doesn't know that sometimes it will need to copy the cookie data as well. A bunch of other functions in that file also assume that they're working on a regular XEvent. Do any more experienced X or GTK developers have any suggestions on how to most cleanly fix this?
Thanks for the analysis, Ricky. This will certainly help in with coming up with a fix. CCing the resident XI2 expert.
*** Bug 662862 has been marked as a duplicate of this bug. ***
The following fix has been pushed: 89c90ed Fix move-resize emulation with XI2
Created attachment 203179 [details] [review] Fix move-resize emulation with XI2