Bug 105881 - Problem with <Shift>+TAB keyboard Navigation on the Standard toolbar
Summary: Problem with <Shift>+TAB keyboard Navigation on the Standard toolbar
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Jim Raykowski
URL:
Whiteboard: target:6.3.0
Keywords: accessibility
Depends on:
Blocks: a11y Toolbars
  Show dependency treegraph
 
Reported: 2017-02-09 13:40 UTC by am_dxer
Modified: 2019-05-21 13:27 UTC (History)
9 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 am_dxer 2017-02-09 13:40:36 UTC
Description:
When using Tab and Shift_Tab to navigate between options in the toolbar, a keyboard trap can be observed.

Steps to Reproduce:
1. Press F6 to access the Standard toolbar.
2. Press Shift+Tab, nothing is spoken by screen readers.
3. Press Tab, nothing is spoken by screen readers.
4. Continue pressing Tab and nothing is spoken by screen readers. The focus does not move to other controls.

Actual Results:  
Focus does not move when pressing the Tab key.

Expected Results:
Using the Tab key should navigate between items on the toolbar and these should be spoken.


Reproducible: Always

User Profile Reset: Yes

Additional Info:
Version: 5.4.0.0.alpha0+
Build ID: 0e0fef10002b46965edad02b3f460a502d9f6595
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-08_23:11:53
Locale: en-US (en_US); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Comment 1 Alex ARNAUD 2017-02-09 14:02:07 UTC
Dear am_dxer,

I can reproduce it on LibreOfficeDev 5.4, not on 5.2 on Debian GNU/Linux 8.7 with the latest release of the orca screen reader.

Best regards.
Comment 2 V Stuart Foote 2017-02-09 15:50:28 UTC
On Windows 10 Pro 64-bit en-US with 
Version: 5.4.0.0.alpha0+
Build ID: 83e059af2203ec0cd15dea08cfa538555ba14bd7
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-06_23:29:13
Locale: en-US (en_US); Calc: group

Confirming the misbehavior of the <Shift>+TAB, and no action of subsequent TAB keys. But not the keyboard trap.

A second <Shift>+TAB restores focus to the Standard toolbar. Not sure where it is directed while the TAB keys are not active.

Also, F10, F6 and <Ctrl>+F6 all return to expected locations.

Interestingly, with the Toolbar undocked, the <Shift>+TAB cycles to the last control of the tool bar as expected, no issues with the toolbar then.
Comment 3 Buovjaga 2018-05-24 13:48:14 UTC
It was said that the problem is not in 5.2 (on Linux). However, on Windows with NVDA I have the problem in both the oldest and latest commit in bibisect repo 5.3. I also have the problem in 5.0.2, 4.4.7 and 4.3.0 beta1.

Therefore I question the regression status.
Comment 4 Alex ARNAUD 2018-05-24 15:35:32 UTC
(In reply to Buovjaga from comment #3)
> It was said that the problem is not in 5.2 (on Linux). However, on Windows
> with NVDA I have the problem in both the oldest and latest commit in
> bibisect repo 5.3. I also have the problem in 5.0.2, 4.4.7 and 4.3.0 beta1.
> 
> Therefore I question the regression status.

Right, it was a misunderstanding. I can reproduce the issue on 4.2 and 5.2 on Linux.

Best regards,
Alex.
Comment 5 Jim Raykowski 2019-05-03 07:22:23 UTC
Hello all,

Here is a patch that provides keyboard navigation wrapping for toolbars and also provides access to the overflow menu.

Testing and comments appreciated.
 
https://gerrit.libreoffice.org/#/c/71718/1
Comment 6 Buovjaga 2019-05-03 12:05:16 UTC
(In reply to Jim Raykowski from comment #5)
> Hello all,
> 
> Here is a patch that provides keyboard navigation wrapping for toolbars and
> also provides access to the overflow menu.
> 
> Testing and comments appreciated.
>  
> https://gerrit.libreoffice.org/#/c/71718/1

I first tried *without* the patch, but I don't observe any of the problems described by am_dxer in 2017. The buttons are read fine, there is no trap.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: f20810f7829d9f3b7167df316e1303810b746366
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 3 May 2019
Comment 7 V Stuart Foote 2019-05-03 12:57:17 UTC
(In reply to Buovjaga from comment #6)
> I first tried *without* the patch, but I don't observe any of the problems
> described by am_dxer in 2017. The buttons are read fine, there is no trap.
> 

Hmm, recent master on Windows 10 Home 64-bit, STR of OP remain reproducible. A <Shift>+Tab from the "New" split button of the Standard menu sends focus somewhere else that <Tab> does not restore. And <Shift>+Tab or F10, F6 does.

@Jim R., push the patch and will test when it rolls...

=-testing-=
Windows 10 Home 64-bit en-US (1809) Intel HD Graphics 620 (dvr 25.20.100.6519)
Version: 6.3.0.0.alpha0+
Build ID: 8f03bdee8225c619305ef210391dcc3b6c6fe284
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 8 Maxim Monastirsky 2019-05-03 13:40:51 UTC
(In reply to Buovjaga from comment #6)
Hmm, I still see the problem with:

Fedora 29
Version: 6.3.0.0.alpha0+
Build ID: 2aed7abb64ded178850f1ecaff98986357086b68
CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

I can also confirm that Jim's patch fixes the problem. Now Shift+Tab moves the focus to the last toolbar item (or to the overflow button if it present), and Tab moves back to the first item, which I consider to be the right behavior. Thanks Jim!
Comment 9 Commit Notification 2019-05-04 00:36:05 UTC
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/3f6fcaa97e3f75c5f12febe821c63f0c2f96e07a%5E%21

tdf#105881 Toolbar keyboard navigation fixes

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Samuel Thibault 2019-05-21 13:27:13 UTC
I can confirm that it is now working as expected, thanks!