Bug 122210 - When using the Orca screen reader on the Toolbars, everything is announced as a scroll pane; probably incorrect accessibility attributes being passed to the accessibility stack.
Summary: When using the Orca screen reader on the Toolbars, everything is announced as...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y, Accessibility GTK3
  Show dependency treegraph
 
Reported: 2018-12-20 00:04 UTC by am_dxer
Modified: 2023-03-13 19:32 UTC (History)
4 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 2018-12-20 00:04:59 UTC
Description:
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.

Actual Results:
Orca announces scroll pane every time TAb is pressed.

Expected Results:
Announce only the control name.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.3.0.0.alpha0+
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
Calc: threaded
Comment 1 am_dxer 2018-12-20 00:08:52 UTC
I produced this on 6.3 but not 6.1. I will try to narrow down where the problem was introduced later.
Comment 2 Patrick ZAJDA 2019-02-16 14:55:05 UTC
I can reproduce this.
Version: 6.3.0.0.alpha0+
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
Calc: threaded

I also reproduce this on LibreOffice 6.1.5.
Version: 6.1.5.1
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
Comment 3 Alex ARNAUD 2019-03-05 09:32:48 UTC
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:
SAL_USE_VCLPLUGIN=gtk libreoffice

I confirm the correct Orca behavior but not with GTK3.

I've added Joanie in CC to have her input about this.

Best regards,
Alex.
Comment 4 Joanmarie Diggs 2019-03-05 09:44:51 UTC
I'm not seeing it in version 6.0.7.3.0+. Will look with a later version in a bit.
Comment 5 Joanmarie Diggs 2019-03-05 11:22:17 UTC
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.
Comment 6 QA Administrators 2023-01-20 03:24:51 UTC Comment hidden (obsolete)
Comment 7 Michael Weghorn 2023-03-13 19:32:49 UTC
I can reproduce broken announcement of toolbar items with

Version: 6.2.6.0.0+
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
Calc: threaded 

but not with current versions, e.g.

Version: 7.5.2.0.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
Calc: threaded

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):

commit f1604675e71c67024887d12bf73ccb86ac05a7a3
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
    
    Change-Id: Ie477aff5cfaa3b64589cb3246ff38d4e57068ead
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86262
    Tested-by: Jenkins
    Reviewed-by: Caolán McNamara
    Tested-by: Caolán McNamara

-> Closing as FIXED