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 741847 - Keyboard navigation of route entries is broken
Keyboard navigation of route entries is broken
Status: RESOLVED OBSOLETE
Product: gnome-maps
Classification: Applications
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gnome-maps-maint
gnome-maps-maint
Depends on:
Blocks:
 
 
Reported: 2014-12-22 08:32 UTC by Jonas Danielsson
Modified: 2018-03-26 12:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GTK object hierarchy involved in the event propagation (43.96 KB, image/png)
2015-04-15 06:42 UTC, Txus Ordorika
Details
Scrolled window classtree (21.29 KB, image/png)
2015-04-19 21:11 UTC, Txus Ordorika
Details

Description Jonas Danielsson 2014-12-22 08:32:30 UTC
It is not possible to tab your way throgh all entries/buttons in the route planner.

It seems that the GtkListBoxRow gets the focus and it does not get propogated to the entry/button.

Anyone want to give a shot of solving this?

To reproduce:

- Open route planner
- Add a few rows
- Try using tab to go through all entries/buttons.
Comment 1 Txus Ordorika 2015-04-15 06:42:03 UTC
Created attachment 301592 [details]
GTK object hierarchy involved in the event propagation
Comment 2 Txus Ordorika 2015-04-15 06:58:03 UTC
Baseline: Every interaction with gnome-maps should be done using the keyboard.
Bug: At some point, the focus gets lost from the input field.

Steps to reproduce:
1.- open gnome maps
2.- Press tab: the focus will move to route icon
3.- Press enter: the gtkgrid sidebar is deployed
4.- write a city/place name, press enter. Gjs_SearchPopUp is shown
5.- Move with the arrows by the list, and press enter whith your choice. The Gjs_PlaceEntry gets populated with the name of the result
6.- Press tab twice to move from first Gjs_PlaceEntry to the next.
7.- Repeat steps 4 and five with the focus in the second Gjs_PlaceEntry
8.- Press enter to get the resultant route painted in the map
9.- The focus gets lost from the window, being impossible to get it back but clicking in any child of the GtkGrid

I've attached the png gtk_object_hierarchy.png for better explanation of the gtk object hierarchy.
https://bugzilla.gnome.org/attachment.cgi?id=301592
Comment 3 Jonas Danielsson 2015-04-15 08:10:47 UTC
Thanks for doing this Txus!

How about when you add new entries to the sidebar? How does the tabbing/focus behave?

If you write some debug code that periodically calls get_focus on the main_window and prints which widget currently has focus, to see where the focus goes.

Maybe with some mainloop.add_time_out sort of call in mainWindow.js?
Comment 4 Txus Ordorika 2015-04-19 21:11:54 UTC
Created attachment 301946 [details]
Scrolled window classtree
Comment 5 Txus Ordorika 2015-04-19 21:38:50 UTC
Baseline: Every interaction with gnome-maps should be done using the keyboard.
Bug: At some point, the focus gets lost from the input field.

Below each step, I've written down the Gtk element with the focus as reported by the main window.

Steps to reproduce:
1.- open gnome maps

2.- Press tab: the focus will move to route icon. 
The Gtk item data is: GIName:Gtk.ToggleButton With name toggleSidebarButton

3.- Press enter: the gtkgrid sidebar is deployed.
The Gtk item data with the focus is: GType:Gjs_PlaceEntry with name null (not set)

4.- Write a city/place name, press enter. Gjs_SearchPopUp is shown.
The Gtk item data with the focus is: GType:Gjs_PlaceEntry with name null (not set). The focus is object is the same as in the previous step.
The parent element of the list with the visual focus (in blue) is GtkScrolledWindow. See attached file [https://bugzilla.gnome.org/attachment.cgi?id=301946].

5.- Move with the arrows by the list, and press enter whith your choice. The Gjs_PlaceEntry gets populated with the name of the result.
Each of those elements that I can move using the arrow keys are GTKGridElements.
Gtk item data with the focus is: GIName:Gtk.ListBoxRow.
The visual focus is the whole text in the Gtk element reported in step 3.

6.- Press tab. 
- Expected result: The focus should move to the [+] Gtkbutton
- Gtk item with focus: GIName:Gtk.ListBoxRow

7.- Press tab again. The focus moves to the second text field.
Gtk item with focus: GType:Gjs_PlaceEntry with name null (not set)

7.- Repeat steps 4 and 5

8.- Press enter to get the resultant route painted in the map
- Expected result: The focus should be in the GtkBox with name instruction-box
- Actual result: Gtk item with focus:  Gjs-WARNING **: JS ERROR: TypeError: this.get_focus(...) is null

9.- The focus gets lost from the window, being impossible to get it back but clicking in any child of the GtkGrid

As requested in https://bugzilla.gnome.org/show_bug.cgi?id=741847#c3:
Once clicked in the Gtk button [+]:
a.- The focus keeps in GType:Gjs_PlaceEntry 
b.- Press tab, and the focus goes to  GIName:Gtk.ListBoxRow
b.- Press tab, and the focus goes to  GIName:Gtk.Button [-]
c.- Press tab, and teh focus goes to GType:Gjs_PlaceEntry, to write down the second route point.

- As user, I'd expect after clicking the [+] button, to have the focus in the second GType:Gjs_PlaceEntry.
- After that, a tab should move focus to the [-] button.
Comment 6 Jonas Danielsson 2015-04-20 09:23:05 UTC
Awesome work!

So the three main issues you see are(?):

a) The focus dissapearing when you get a route
b) The focus not going to the [+] button on tab
c) The focus not going to the new entry when pressing [+]

So for a) I wonder if we maybe could add something in sidebar.js.
In initInstructionList, in the signal handler for the 'update' signal from the route object.
You could try adding an explicit this._instructionList.grab_focus(); at the bottom.


So, b) and c) are trickier. A GtkListBoxRow is a helper object for GtkListBox, reading the documentation for that object would be a good start. Then trying to figure out if we are doing something wrong, or if it is a GTK issue. We add routeEntry objects to the ListBox, so its source is in src/routeEntry.js and data/ui/routeEntry.ui, maybe we are doing something fishy with the can-focus property?

We need to learn about focus handling I guess :)

Great work so far!

Let me know if you grow bored of this and want to look at something else!
Comment 7 Txus Ordorika 2015-04-21 06:56:19 UTC
a) Seems a good starting point, but adding the suggested instruction in __initInstructionList__ in the 'update' signal (sidebar.js L199), seems to have no effect.

For me it'd make sense that the first GtkBox containing the "Start" word in it should get the focus. But inspecting that object with GtkInspector says that the property can_focus is set to False. All the GtkBox instances in each Gjs_Instruction row have this property set to false. 

I wondoer if I'm following the right path...

b) and c) are stalled till I solve a)
Comment 8 Jonas Danielsson 2015-04-21 07:38:39 UTC
(In reply to Txus Ordorika from comment #7)
> a) Seems a good starting point, but adding the suggested instruction in
> __initInstructionList__ in the 'update' signal (sidebar.js L199), seems to
> have no effect.
> 
> For me it'd make sense that the first GtkBox containing the "Start" word in
> it should get the focus. But inspecting that object with GtkInspector says
> that the property can_focus is set to False. All the GtkBox instances in
> each Gjs_Instruction row have this property set to false. 
> 

I understand that, but no, the box is only a part of the InstructionRow class, src/instructionRow.js, data/ui/instruction-row.ui, we want the whole row to get focus. And to that effect I think what you want to do is something like:

let row = this._instructionList.get_row_at_index(0);
row.grab_focus();

At the same place you tried before. Maybe with a comment that we want the first row to get comment when we get a new row.

> I wondoer if I'm following the right path...
> 
> b) and c) are stalled till I solve a)

Keep looking at GtkListBox, for clues.

Thanks!
Comment 9 Jonas Danielsson 2015-04-23 10:12:18 UTC
One thing that makes this a bit more complicated.

If you add a bunch of route entries, with the objective to do a route with via points. When you have filled in two of them, with valid entries, you will get a route, and the focus will go to the instruction list, would not the expected behavior be to go to the next empty route entry?
Comment 10 GNOME Infrastructure Team 2018-03-26 12:45:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-maps/issues/20.