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
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.
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.
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.
(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.
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
(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
(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
(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!
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.
I can confirm that it is now working as expected, thanks!