office-gobmx/winaccessibility
Michael Weghorn 836a226205 tdf#100086 wina11y: Don't delete a11y object for removed cell right away
When handling a SELECTION_CHANGED_REMOVE event,
AccDescendantManagerEventListener previously emitted a corresponding
EVENT_OBJECT_SELECTIONREMOVE MSAA event with the removed child's ID
as a parameter, then deleted that child's accessibility object.

This resulted in the accessibility object no longer being available
if accessibility tools queried for the object just received in
the EVENT_OBJECT_SELECTIONREMOVE event.

As a consequence, no 'event_selectionRemove' would be triggered
for any table cell object on NVDA side, so an updated selection
would not be announced for that case.

To keep child objects available for such cases, don't delete the
corresponding object in the handler for the SELECTION_CHANGED_REMOVE
handler, but remember it for deletion and only do the actual deletion
once a subsequent different event is handled.

With this in place, the announcement for multiple selected cells in
Calc generally works with the NVDA screen reader and a pending
NVDA pull request [1] by Leonard de Ruijter in place
(s.a. discussion in NVDA issue [2] for more background
and further information).

(There are still cases where events in response
to selection changes are missing, as described e.g. in
tdf#118508 and tdf#118748, but those are not winaccessibility-specific
and it's the same when using the gtk3 VCL plugin with the Orca screen
reader on Linux.)

[1] https://github.com/nvaccess/nvda/pull/12849
[2] https://github.com/nvaccess/nvda/issues/9310

Change-Id: I7a46060c501ba9b8288e7c127121a535c60ce2bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122169
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-09-16 09:25:36 +02:00
..
inc tdf#100086 wina11y: Don't delete a11y object for removed cell right away 2021-09-16 09:25:36 +02:00
source tdf#100086 wina11y: Don't delete a11y object for removed cell right away 2021-09-16 09:25:36 +02:00
CustomTarget_ia2_idl.mk
Library_uacccom.mk tdf#100086 tdf#124832 wina11y: Implement IAccessibleTableCell 2021-09-08 20:06:00 +02:00
Library_winaccessibility.mk
Makefile
Module_winaccessibility.mk
README.md
WinResTarget_uacccom.mk

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 NVDA is running when soffice starts, IA2 should be automatically enabled and work as expected. In order to use 'accprobe' to debug it is necessary to override the check for whether an AT (like NVDA) is running; to do that use:

SAL_FORCE_IACCESSIBLE2=1 soffice.exe -writer

Then you can use accprobe 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.