Bug 122900 - When opening the navigator, the caret is no longer positioned on the list
Summary: When opening the navigator, the caret is no longer positioned on the list
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0 target:6.2.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Navigator
  Show dependency treegraph
 
Reported: 2019-01-23 14:01 UTC by Alex ARNAUD
Modified: 2019-03-12 18:15 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex ARNAUD 2019-01-23 14:01:00 UTC
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 sha:88cbc3ea2db8358bbedff01361f95f972f2b0231
    
    source sha:88cbc3ea2db8358bbedff01361f95f972f2b0231

:040000 040000 baa5bc17a9aa793ff76a6159f5b148f80ca0e404 63720c49c270805594663a73b8993c674d14ea68 M	instdir
Comment 1 Xisco Faulí 2019-01-23 17:42:44 UTC
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
Comment 2 Heiko Tietze 2019-01-24 14:52:15 UTC
Guess it slipped in with the rework for styles (F11).
Comment 3 Jim Raykowski 2019-01-25 05:20:33 UTC
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
Comment 4 Alex ARNAUD 2019-01-25 08:17:34 UTC
(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.
Comment 5 Jim Raykowski 2019-01-27 00:10:56 UTC
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/
Comment 6 Cor Nouws 2019-02-06 23:02:40 UTC
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.
Comment 7 Jim Raykowski 2019-02-09 23:45:14 UTC
(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.
Comment 8 Heiko Tietze 2019-02-10 09:34:48 UTC
(In reply to Jim Raykowski from comment #7)
> Maybe Samuel Mehrbrodt could add thoughts to this discussion...
Comment 9 Heiko Tietze 2019-02-14 13:37:36 UTC
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
Comment 10 Cor Nouws 2019-02-14 13:59:23 UTC
(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.
Comment 11 Jim Raykowski 2019-02-15 22:22:09 UTC
I have reverted the patch for bug 49684 which will return the Navigator focus behavior to focus on the content tree list on show.
Comment 12 Heiko Tietze 2019-02-18 11:10:36 UTC
(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 ;-)
Comment 13 Alex ARNAUD 2019-02-27 17:25:53 UTC
(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.