Files
loongoffice/winaccessibility
Michael Weghorn a3773ad48a tdf#153131 wina11y: Return error code when child count exceeds max long
When the accessible child count exceeds max long,
no longer return max long in the IAccessible::get_accChildCount [1]
implementation in the Windows a11y bridge, but instead return error
code `S_FALSE` [2]:

> The method succeeded in part. This happens when the method succeeds, but
> the requested information is not available. For example, Microsoft
> Active Accessibility returns S_FALSE if you call IAccessible::accHitTest
> to retrieve a child object at a given point, and the specified point is
> not within the object or the object's child.

This prevents the problem that Windows Speech Recognition on Windows 10
(see tdf#153131) and apparently some tools on Windows 11 that query
information from LO via the accessibility API (see tdf#165131 and
tickets referenced from there) apparently try to iterate over all
children from child index 0 to (excluding) the returned index
unconditionally, which causes a freeze if the returned number is too large.

In practice, this is known to be a problem with Calc sheets, for which
all cells are currently considered direct children.

A quick test with NVDA and this change in place didn't reveal any
issues.
(Independent of this change, using JAWS 2025.2412.50 instantly
results in a crash somewhere in the AT code that gets run
in-process, preventing to test what implications this change
would have there otherwise.)

[1] https://learn.microsoft.com/en-us/windows/win32/api/oleacc/nf-oleacc-iaccessible-get_accchildcount
[2] https://learn.microsoft.com/en-us/windows/win32/winauto/return-values

Change-Id: If12dbcbb387a765bec4194d2bfe61bd29aa0f8a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181370
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 9ee01d58771b8ea585698094019b1a4dd38e54eb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181379
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2025-02-11 16:15:49 +01:00
..
2024-10-19 15:52:43 +02:00

Windows Accessibility Bridge

This code provides a bridge between our internal Accessibility interfaces (implemented on all visible 'things' in the suite: eg. windows, buttons, entry boxes etc.) - and the Windows MSAA / IAccessible2 COM interfaces that are familiar to windows users and Accessible Technologies (ATs) such as the NVDA screen reader.

The code breaks into three bits:

  • source/service/

    • the UNO service providing the accessibility bridge. It essentially listens to events from the LibreOffice core and creates and synchronises COM peers for our internal accessibility objects when events arrive.
  • source/UAccCom/

    • COM implementations of the MSAA / IAccessible2 interfaces to provide native peers for the accessibility code.
  • source/UAccCOMIDL/

    • COM Interface Definition Language (IDL) for UAccCom.

Here is one way of visualising the code / control flow

VCL <-> UNO toolkit <-> UNO a11y <-> win a11y <-> COM / IAccessible2

vcl/ <-> toolkit/ <-> accessibility/ <-> winaccessibility/ <-> UAccCom/

Threading

It's possible that the UNO components are called from threads other than the main thread, so they have to be synchronized. It would be nice to put the component into a UNO apartment (and the COM components into STA) but UNO would spawn a new thread for it so it's not possible. The COM components also call into the same global AccObjectWinManager as the UNO components do so both have to be synchronized in the same way.

So we use the SolarMutex for all synchronization since anything else would be rather difficult to make work. Unfortunately there is a pre-existing problem in vcl with Win32 Window creation and destruction on non-main threads where a synchronous SendMessage is used while the SolarMutex is locked that can cause deadlocks if the main thread is waiting on the SolarMutex itself at that time and thus not handing the Win32 message; this is easy to trigger with JunitTests but hopefully not by actual end users.

Debugging / Playing with winaccessibility

If an assistive technology like NVDA is running when soffice starts, IA2 should be automatically enabled and work as expected.

'accprobe' can be used to introspect the accessibility hierarchy remotely, checkout:

http://accessibility.linuxfoundation.org/a11yweb/util/accprobe/

But often it's more useful to look at NVDA's text output window.

Another tool is Accessibility Insights for Windows: https://accessibilityinsights.io/ It does not support IAccessible2, but the Microsoft Active Accessibility to Microsoft UIA proxy makes some properties, methods and events available to UIA via the LegacyIAccessible pattern: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementinglegacyiaccessible