GNOME Bugzilla – Bug 60690
Behavior of left and right arrows strange when widgets are vertically aligned
Last modified: 2011-02-04 16:16:03 UTC
Run the test program testgtk and click on "radio buttons" button. Press Tab key to get focus to first button. Press right arrow key and focus changes to second button. Press right arrow key again but focus does not move. Press Up arrow key to get focus to first button. Press left arrow key and focus changes to third button. Press left arrow key again but focus does not move.
Basically,what is happening is that right takes you out of the dialog to the right, you reenter from the left, and when you enter a container and don't have more information you enter in the middle. gtkcontainer.c:old_focus_coords() is meant to handle situations similar to this by getting "more information" by looking at the position of the last focus widget, but doesn't seem to handle the case where you focus out of the window and back in. I'm not sure how easy this would be to fix.
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
This is not simple to fix; we'd have to add a _gtk_window_get_last_focus_widget() To get it right for gtkcontainer.c, and have to export that to get it right in general. Since arrow keys for navigating focus have all sorts of other problems, moving it off the 2.0.0 milestone.
I don't see the above behavior anymore and seems to be fixed. But given the lifetime of the bug, not sure where and when it got fixed. Padraig or Calum: Can you confirm ?
pasu: I'm still seeing this in last night's build (9-Jul).
Oops, that's 9-Aug, not 9-Jul :)
I think I'm now seeing this problem with gcalctool (a calculator program). If you start gcalctool in basic mode, the "7" key initially has keyboard focus. Keep hitting the right arrow key and the keys to the right of it are selected (correctly), but after the "Clr" key, the next one selected is "0", where I was expecting either "7" or "4" (not sure what the spec. says). Owen, is there anything I can do programatically to work around this if it's really hard to fix?
The same problem occurs with gnome-calculator.
You could connect to the ::focus signal on the GtkTable that holds the button, do your own thing and return TRUE to indicate that you've handled it. Probably wouldn't be that hard to get whatever behavior you expect, though I'm not sure it is worth the effort.
*** Bug 106627 has been marked as a duplicate of this bug. ***
Note that I attached a small patch to bug #106627 that correctly handles the Tab focus direction case. This might be of interest to others that have an immediate need to work around this problem. For completeness it would have to handle the "edge" cases for all the other directions, in all three modes, so it would start to get large/ugly. The real fix should be to handle the overall problem (i.e this bug).
What happens here is that when focus is at the edge of the window and you press right arrow all ::focus implementations from the focus widget up will return FALSE. This will make the GtkWindow::focus() method set_focus_child (NULL) in all containers and then try focusing again. Since there is no current focus at this point, the default container::focus() implementation will focus the middle widget in the left-most column. What widget that is, is essentially unpredictable. Possible solutions: - Make all containers maintain a "last focus". Then the focus implementation could just use this instead of calculating an "old focus". Note that the implementation of this could probably use the implementation in gtkpaned.c, which could then be removed. - Make arrow keyboard navigation not wrap around. Doing this would require special casing arrows in GtkWindow::focus. Home and End navigation could probably be added.
I should add that the solution to this bug will have implications for bug 54047.
Created attachment 15397 [details] [review] patch to make arrows not wrap
I'm fine with this change for HEAD. I'd rather not do it for GTK+-2.2; not that I think it would break anything, but just on a general idea of avoiding behavior changes in the stable branch.
committed to HEAD