GNOME Bugzilla – Bug 711366
Keyboard focus is impractical during Process searching
Last modified: 2013-11-05 21:45:45 UTC
Created attachment 258891 [details] [review] Process tree view grabs focus when user press TAB in search entry When I am searching for a process in the "Process" tab making use of the search bar feature, it's difficult to get focus again in the process list using the keyboard. If I press TAB when searching, the list view does not get the keyboard focus, which is (at least for me) the wrong behavior. If you consider this issue applicable, I want to propose a patch for it. The patch just change the focus on process list when user press TAB on search entry. Besides, I think it would be convenient to allow users to get focus again on search entry by pressing Shift-TAB and/or, more general, that search entry get focus when user press Ctrl-F and search entry isn't focused (both when search bar is showed or not). Actually, if user wants to get focus again on search entry using keyboard when search bar is already showed, user needs to press Ctrl-F twice, loosing the current search. Cheers!
I agree with what you are proposing, to make the Tab key jump back to the list. Thank you for the patch too, however I have seen in another bug report (can't remember which one) that handling the tab key event is not the best way to achieve focus ordering, gtk_container_set_focus_chain should be used. I have been experimenting with it, but so far I haven't managed to get the Tab key move the focus out of the headerbar. I will be asking around, or if you manage to do something, I'll accept a refined patch, using focus chain setting, but if there's no other way, I'll get this, as this solution is better than nothing. Ctrl+F focusing the searchbar again is a good idea, let's discuss that in a separate ticket, bug 711381.
Review of attachment 258891 [details] [review]: Commented in the ticket, I'd rather see tab focus order solved with gtk_container_set_focus_chain, but if that won't work, something like this will do fine.
Thanks for the review, I have arrived to gtk_container_set_focus_chain as one of the possible solutions because the Shift-Tab issue but I didn't try that (I could not see an obvious container here). Today, after my work I will try to achieve the focus chain solution and give you a little report (I hope that the report become part of the commit message ;))
Well, today I was trying to get the focus chain working, but unsuccessfully. What I was trying to do is to set the focus chain to the common parent between the search bar and process tree view, which is the "proc_box" container (present in interface.ui), then I tried to play with different widgets chains: - Search entry and Process tree view - Search bar and proclist_box - Search entry and Process scrolled window (tree view parent) - Title bar, search entry and process tree view (setting the focus chain to the main window) - and more... Then, obviously I've stopped because I was doing it blindly :P . I noticed (just like you) that the keyboard focus, no matter what I do, always changes to the title bar controls and if I press TAB multiple times, keyboard focus iterates only over the title bar widgets: tabs -> search button -> configuration button -> close window button -> unknown/no widget -> tabs again -> ... If I press TAB with the current focus in any widget, the focus magically goes to the title bar. For example, if I get focus on "End Process" button and press TAB, the focus changes to the mentioned unknown/no widget, then the tabs, etc, instead of change to "Show process properties" button. I also tried to check other GNOME components source code to find any clue [1]... but I could not find anything relevant. Any thought? [1] https://github.com/search?q=gtk_container_set_focus_chain+user%3AGNOME&type=Code (I used GitHub for search just for convenience)
Thank you for your help with this bug. I don't know where we could find example usage of focus chain overriding in GNOME projects, but I guess that's not the problem, as experimenting should help us there, BUT the headerbar is blocking us from doing that :) So I have reported bug 711466 for gtk+, let's see what the devs have to say about that, and I will start bugging them on IRC, as it's kindof strange that such an anti-a11y bug has slipped in 3.10 :) If you want, add yourself as a CC on that bug.
*** Bug 711466 has been marked as a duplicate of this bug. ***
I have fixed this in the trunk, I'd appreciate if you would test it. For me, tabbing from the searchbar moves the focus to the tree, after selecting a row, tab moves to the end process, then to the process properties. If you're interested, check commit 56257704c189a42f46097ddb968c4c97dabd837c [1] With Ctrl+F going back to the searchbar again, and not hiding it I'm stuck, so if you have any ideas there, please comment on bug 711381. I have managed to do that, and on first ctrl+F the search entry appears, I enter some text, on the next Ctrl+F the focus goes back, but if I press Escape to hide the searchbar, it's hidden, but Ctrl+F won't show it anymore. [1] https://git.gnome.org/browse/gnome-system-monitor/commit/?id=56257704c189a42f46097ddb968c4c97dabd837c