GNOME Bugzilla – Bug 386618
Resizing columns need focusing first
Last modified: 2007-10-09 19:57:59 UTC
That bug has been described on https://launchpad.net/bugs/62898 "Open a folder in nautilus with the list view enabled in the right pane. Now click inside the right pane, so it gets focus. Try to resize one of the columns by moving the mouse to the small vertical bar between the column headings and pressing and holding the left mouse button. You can move the mouse around without anything happening. What you need to do first (and that's what I consider being the bug) is clicking the column headings control in order to give it the focus (there's no visual feedback for this though). I hope that I filed this bug correctly. But please correct me if this is a GTK or theme dependent bug"
I cannot reproduce this bug (not even on my ubuntu system). Steps I used: 1. Open Nautilus. 2. Make sure right pane is in "list mode". 3. Click on the right pane so one of the nodes receives focus. 4. Move the mouse to a column header separator; the mouse cursor changes. 5. Press and hold left mouse button to resize the column. It works as expected (gtk+ 2.10.6-0, nautilus 2.16.1-0). Please tell me if I am trying to reproduce the bug in the right way. If the steps above should lead to the problem I would conclude that this is not a bug in gtk+.
(I have no idea why this bug suddenly changed state).
With the same steps and the same version of GTK the first click and dnd doesn't resize the column on an Ubuntu desktop, you need to click and dnd again to actually change the column. The same happens to other applications like gnome-system-monitor
Really interesting; really cannot reproduce it here.
The same bug was described here: http://bugs.debian.org/406906 I can reproduce the same behavior on my system, in nautilus or file-roller, and as for the submitter, this happens only after opening a directory in file-roller, or unfolding it in nautilus. After that, the first attempt to resize the column always fails, and the second attempt is OK.
I played with gdb a bit. The problem is that when starting dragging, a GRAB_BROKEN event is signalled immediately canceling the dnd operation. The relevant code lies in gtktreeview.c, so it is clearly a GTK problem. The grab_broken-event has 'implicit' set to 1, 'keyboard' to 0, 'window' is bin_window and 'grab_window' is the column window that is being dragged. Hope that helps a bit.
Hi, I found the cause for the bug and I also know why Kristian Rietveld most probably couldn't reproduce it: He didn't have NumLock on. This explanation may sound weird at the first moment, but the bug lies way deeper than in gtktreeview.c as I thought initially. When you click inside the non-column-area of a GtkTreeView, GTK+ will believe there is an implicit pointer grab even after releasing all mouse buttons. Trying to resize the columns then fails. GTK+ is trying to abort the implicit grab (which it thinks is still present) by issuing a grab_broken_event. At this instant, GtkTreeView internally thinks that it is in already resizing the columns so that the grab_broken_event-handler aborts this operation. The actual bug lies in gdk/x11/gdkmain-x11.c in the function _gdk_xgrab_check_button_event(). When a button is released, it checks if there are still buttons pressed. This check is broken. It should be checked for still pressed buttons only (minus the one just released) and NOT for modifiers. On my machine, the NumLock key is MOD2MASK (1<<4), so that the condition (xevent->xbutton.state & ~(GDK_BUTTON1_MASK << (xevent->xbutton.button - 1))) == 0) returns false. This causes that display_x11->pointer_xgrab_window is _not_ reset to NULL. A quick fix would be replacing the condition with (~0xff & xevent->xbutton.state & ~(GDK_BUTTON1_MASK << (xevent->xbutton.button - 1))) == 0) since the least 8 bits are used for modifier masks (like SHIFT, CTRL etc.) and should be ignored.
Component GDK, as has been pointed out in #bugs. FWIW, I believe I have seen this very behavior too recently. Didn't have the time to find a pattern yet, though.
(In reply to comment #7) > I found the cause for the bug and I also know why Kristian Rietveld most > probably couldn't reproduce it: He didn't have NumLock on. > This explanation may sound weird at the first moment, but the bug lies way > deeper than in gtktreeview.c as I thought initially. Ah, that's correct! With NumLock on I can indeed reproduce the bug. Thanks for investigating and moving this to gdk!
Created attachment 82462 [details] [review] patch already mentioned above This patch masks out the modifier bits like shift/ctrl/numlock so that an implicit grab is actually released upon mouse button release while a modifier is present.
Thanks for pointing that out. I've committed a slightly different patch. 2007-02-15 Matthias Clasen <mclasen@redhat.com> * gdk/x11/gdmain-x11.c (_gdk_xgrab_check_button_event): Be more careful when checking for ButtonRelease events that end implicit grabs. (#386618, Christof Krüger)
*** Bug 460233 has been marked as a duplicate of this bug. ***