As the user tabs through the toolbars, scroll pane is announced every time a new control is focused.
Steps to Reproduce:
1. Run the Orca screen reader and the GTK3 version of Libreoffice.
2. Press F6 twice to focus the toolbar.
3. Press TAb to move between the controls.
Orca announces scroll pane every time TAb is pressed.
Announce only the control name.
User Profile Reset: Yes
Build ID: 6dc36d343aeacb3d1e14ec0c847937d63f4e68a7
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
I produced this on 6.3 but not 6.1. I will try to narrow down where the problem was introduced later.
I can reproduce this.
Build ID: aa31976c2e4399a86bc6f70f140972d9ccef6fc0
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3;
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-12_16:47:45
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
I also reproduce this on LibreOffice 6.1.5.
Build ID: 1:6.1.5~rc1-2~bpo9+1
Threads CPU : 2; OS : Linux 4.9; UI Render : par défaut; VCL: gtk3;
Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded
I'm reproducing this both on LibreOffice 6.1.5 and LibreOfficeDev 6.3, both with Orca master and Orca 3.30.
I confirm the regression only between GTK2 etn GTK3 VCL.
If I install GTK2 version of LibreOffice 6.1.5 and run it with this:
I confirm the correct Orca behavior but not with GTK3.
I've added Joanie in CC to have her input about this.
I'm not seeing it in version 220.127.116.11.0+. Will look with a later version in a bit.
So I can confirm this using 6.2 from flathub. What's happening (not surprisingly, given the opening report) is that a scroll pane keeps claiming focus immediately after the newly-focused toolbar button. Those focus claims from the accessible object with role scroll pane need to stop happening.
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
I can reproduce broken announcement of toolbar items with
Build ID: d250c94d78ac7e79753aa30f869db919b01fc450
CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3;
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
but not with current versions, e.g.
Version: 18.104.22.168.0+ (X86_64) / LibreOffice Community
Build ID: 1e7ee035992a0b29f42eac56ad82e2a1b0fe8ccd
CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
Bibisecting shows that it works fine from this commit on (after being even more broken in between with broken keyboard navigation, s.a. the bug that the commit message references):
Author: Caolán McNamara
Date: Mon Jan 6 10:30:51 2020 +0000
tdf#129634 send SalEvent::LoseFocus only if some other widget gains focus
not if we "lose" focus to nothing before we would regain it again
Reviewed-by: Caolán McNamara
Tested-by: Caolán McNamara
-> Closing as FIXED