Description: Since version 6.2, when opening the navigator the caret is no longer positioned correctly. I assume it's a mistake because I don't see any reason to positioned the caret on the top-left corner instead of directly inside the item list. As navigator is intended for navigation I assume positioned the keyboard on the navigation pane (headings, tables, etc) looks like IMO a more reliable way. Steps to Reproduce: 1. Open LibreOffice Writer 6.2 or a daily build of 6.3 2. Press F5 to open the navigator floating window Actual Results: The caret is on the top-left corner of the floating window Expected Results: The caret should be on the first item of the main widget so on the list of element (headings, table, etc) Reproducible: Always User Profile Reset: No Additional Info: I've bibisected, the regression comes there: d20159a69b20b08d01faa4c7685616fef66bef6d is the first bad commit commit d20159a69b20b08d01faa4c7685616fef66bef6d Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Nov 1 10:50:19 2018 +0100 source 88cbc3ea2db8358bbedff01361f95f972f2b0231 source 88cbc3ea2db8358bbedff01361f95f972f2b0231 :040000 040000 baa5bc17a9aa793ff76a6159f5b148f80ca0e404 63720c49c270805594663a73b8993c674d14ea68 M instdir
Reproduced in Version: 6.3.0.0.alpha0+ Build ID: 0d46fb02f3f19d11db40b6c5335d78a3894502d7 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded Adding Cc: to Jim Raykowski
Guess it slipped in with the rework for styles (F11).
Making the navigator not grab focus to the content tree on show was intentionally done to resolve: Bug 49684 - the Navigator gets the focus when starting a new document while the Navigator is open commit 88cbc3ea2db8358bbedff01361f95f972f2b0231 Author: Jim Raykowski <raykowj@gmail.com> Date: Mon Oct 22 17:38:31 2018 -0800 tdf#49684 Don't focus on Navigator or Sidebar on show Change-Id: I21b36c3ed2e5b6fc574e00f86d2c48c352cf469c This works for GTK2 but not for GTK3, which I did not know until recently. The following patch causes it not to work for GTK3: Bug 98807 - GTK3: Activate the navigator doesn't get focus to the navigator window commit c0d6fa1417141a3a7e9deb2f4d50acc28b32f1b4 Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Oct 18 15:37:59 2016 +0100 Resolves: tdf#98807 gtk3 isn't giving utility windows focus so just give up on that and give them a dialog hint instead Change-Id: Icca0c707dc464b0dbf362988b1dfee56866eadc0 I tested patching GTK2 in vcl/unx/gtk/gtksalframe.cxx the same as Caolán's GTK3 patch. It works but re-introduces bug 49684 for GTK2. A related bug is: Bug 113250 - UI Navigator ('floating' version, that is in docked state) in Calc doesn't have the focus immediately after opening with F5
(In reply to Jim Raykowski from comment #3) > Making the navigator not grab focus to the content tree on show was > intentionally done to resolve: Thanks Jim and all for working for fixing issues on LibreOffice. Unfortunately from what I understand, solving the issue you've mentioned create this one and makes the navigator more difficult to use for keyboard-only users like blind people. Could we imagine to fix the issues you've mentioned without changing the focus/caret position at navigator startup ? Best regards, Alex.
Hi Alex, It is a pleasure to discussing this with you. Thank you for your contribution to sidebar guidelines. They were used in recent keyboard navigation improvements made to the sidebar. F5 navigator and sidebar navigator use the same code. Having the navigator tree grab focus makes the action of navigator selection on first opening in the sidebar differ in behavior from all other decks. Mouse click or keyboard simulated mouse click using space key, will not return focus to the document, instead navigator tree grabs focus, see bug 120231. Focusing to the navigator tree as well as the current behavior actually goes against guideline 9 for tab bar [1]. Thank you for the work you have done there :). 9. Expand or collapse the deck with space but stay at the tabbar. Current F5 and menu->view->navigator focus behavior is focus/caret remains in document for gtk2 and windows and gtk3 focus moves navigator window for reason mentioned in previous post. Reason not to focus to navigator window on show is also discussed in previous post. > Could we imagine to fix the issues you've mentioned without changing the > focus/caret position at navigator startup ? Yes I did try but was unsuccessful in finding a way to accomplish this. I'm for whatever is decided to be best. [1] Guidelines for keyboard navigation in the sidebar https://design.blog.documentfoundation.org/2017/02/16/guidelines-for-keyboard-navigation-in-the-sidebar/
Hi Jim, I already thanked you for working on all these items, and.. (In reply to Jim Raykowski from comment #5) > > Could we imagine to fix the issues you've mentioned without changing the > > focus/caret position at navigator startup ? > > Yes I did try but was unsuccessful in finding a way to accomplish this. > > I'm for whatever is decided to be best. If the choice (at length..) is between Navigator gets focus (sometimes) on launching document and Navigator never gets focus when it is activated in an open document I consider the latter to be worse.
(In reply to Cor Nouws from comment #6) > If the choice (at length..) is between > Navigator gets focus (sometimes) on launching document > and > Navigator never gets focus when it is activated in an open document > I consider the latter to be worse. Maybe Samuel Mehrbrodt could add thoughts to this discussion. He was kind to contribute time to review and commit the patch I made for Bug 49684 which changed the behavior being discussed in this bug report.
(In reply to Jim Raykowski from comment #7) > Maybe Samuel Mehrbrodt could add thoughts to this discussion...
We discussed the topic in the design meeting. While the guideline [1] is clear how a11y goes through focusable controls, styles are accessed per F11, which jumps directly to the list. So we should do the same here: opening the Navigator with F5 should focus the first list item but going per F6 through the controls has to start at the Navigator's toolbar. [1] https://wiki.documentfoundation.org/Design/SideBar
(In reply to Heiko Tietze from comment #9) > ... So we should > do the same here: opening the Navigator with F5 should focus the first list > item Please unless in Content Navigation View, in which case the current header under which the carret is, gets selected. Thanks.
I have reverted the patch for bug 49684 which will return the Navigator focus behavior to focus on the content tree list on show.
(In reply to Jim Raykowski from comment #11) > I have reverted the patch for bug 49684 which will return the Navigator > focus behavior to focus on the content tree list on show. Thanks, one issue fixed another reopened ;-)
(In reply to Heiko Tietze from comment #12) > (In reply to Jim Raykowski from comment #11) > > I have reverted the patch for bug 49684 which will return the Navigator > > focus behavior to focus on the content tree list on show. > > Thanks, one issue fixed another reopened ;-) I confirm the resolution of the fix with: Version: 6.3.0.0.alpha0+ Build ID: 140fd0a1b1da1b0b14bda17c926dd8f95750ba92 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-26_01:24:44 Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded Thanks all for your involvement on this issue. Best regards, Alex.