office-gobmx/winaccessibility
Michael Weghorn b608604d0b tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible
By default, a vcl::Window's XAccessible is its
VCLXWindow (toolkit peer):

    css::uno::Reference< css::accessibility::XAccessible > Window::CreateAccessible()
    {
        css::uno::Reference< css::accessibility::XAccessible > xAcc( GetComponentInterface(), css::uno::UNO_QUERY );
        return xAcc;
    }

However, that's a virtual method and subclasses can
return a different XAccessible.
MenuFloatingWindow::CreateAccessible returns the
accessible of its menu.

However, winaccessibility's AccTopWindowListener
code was relying on the Window's XAccessible always
being its VCLXWindow.

The VLCXWindow is passed as a param in the
XTopWindowListener methods, and AccTopWindowListener
was querying it for the XAccessible interface, and
then calling XAccessible::getAccessibleContext in
order to retrieve the XAccessibleContext for the
window.

This is incorrect if the Window actually has another
XAccessible.

For the df#164093 scenario with NVDA running, opening and
closing the sidebar popup menu would result in the
VCLXWindow's VCLXWindow::getAccessibleContext menu
getting called, which calls VCLXWindow::CreateAccessibleContext
and the VCLXWindow would keep a reference to the
returned XAccessibleContext and dispose it when
the VLCXWindow itself gets disposed.
However, AccessibleFactory::createAccessibleContext
(called by VCLXWindow::CreateAccessibleContext)
doesn't actually create a new object for the
MenuFloatingWindow's accessible, but returns the
existing accessible object of the PopupMenu, which is
owned by the PopupMenu, not the MenuFloatingWindow,
s.a. previous commit

    Change-Id: Ia2931bee23204395e8b3396927acf4fa1d0f077c
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Thu Dec 5 11:06:48 2024 +0000

        tdf#164093 tdf#157001 a11y: Improve menu window disposal

for more details.

Backtrace of how that accessible context was returned:

    1 `anonymous namespace'::AccessibleFactory::createAccessibleContext acc_factory.cxx 305 0x7fffbc160767
    2 VCLXWindow::CreateAccessibleContext vclxwindow.cxx 879 0x7fffc0b1bc67
    3 VCLXWindow::getAccessibleContext vclxwindow.cxx 2418 0x7fffc0b2670b
    4 AccTopWindowListener::HandleWindowOpened AccTopWindowListener.cxx 60 0x7fffe5c32ab6
    5 AccTopWindowListener::windowOpened AccTopWindowListener.cxx 119 0x7fffe5c3375e
    6 ``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>::operator() vclxtoolkit.cxx 2364 0x7fffc0af27ef
    7 comphelper::OInterfaceContainerHelper4<com::sun::awt::XTopWindowListener>::forEach<``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>> interfacecontainer4.hxx 349 0x7fffc0ae7f9e
    8 `anonymous namespace'::VCLXToolkit::callTopWindowListeners vclxtoolkit.cxx 2359 0x7fffc0afeaed
    9 `anonymous namespace'::VCLXToolkit::eventListenerHandler vclxtoolkit.cxx 2295 0x7fffc0b02492
    10 `anonymous namespace'::VCLXToolkit::LinkStubeventListenerHandler vclxtoolkit.cxx 2288 0x7fffc0afbdf6
    11 Link<VclSimpleEvent &,void>::Call link.hxx 111 0x7fffbfba33d3
    12 VclEventListeners::Call vclevent.cxx 47 0x7fffbfba35f1
    13 Application::ImplCallEventListeners svapp.cxx 733 0x7fffbfb76dbb
    14 vcl::Window::CallEventListeners event.cxx 229 0x7fffbf45f841
    15 vcl::Window::ImplSetReallyVisible window.cxx 1331 0x7fffbf566bad
    16 vcl::Window::ImplSetReallyVisible window.cxx 1344 0x7fffbf566c7d
    17 vcl::Window::Show window.cxx 2336 0x7fffbf56a8d1
    18 vcl::Window::Show window.cxx 2349 0x7fffbf56a9ce
    19 FloatingWindow::StartPopupMode floatwin.cxx 825 0x7fffbf46a702
    20 PopupMenu::Run menu.cxx 3018 0x7fffbf4a6f02
    ... <More>

When the MenuFloatingWindow gets disposed, its
VCLXWindow is also disposed. Since it incorrectly
assumes it (or its Window) owns the XAccessibleContext,
it disposes that as well:

    1 OAccessibleMenuBaseComponent::disposing accessiblemenubasecomponent.cxx 608 0x7fffbf300c82
    2 cppu::WeakComponentImplHelperBase::dispose implbase.cxx 104 0x7fffe199964a
    3 cppu::PartialWeakComponentImplHelper<com::sun::accessibility::XAccessibleContext2,com::sun::accessibility::XAccessibleEventBroadcaster>::dispose compbase.hxx 90 0x7fffdb8d1820
    4 VCLXWindow::dispose vclxwindow.cxx 938 0x7fffc0b24012
    5 UnoWrapper::WindowDestroyed unowrapper.cxx 302 0x7fffc0cfddc6
    6 vcl::Window::dispose window.cxx 220 0x7fffbf56e68f
    7 SystemWindow::dispose syswin.cxx 107 0x7fffbf515606
    8 FloatingWindow::dispose floatwin.cxx 225 0x7fffbf46b751
    9 MenuFloatingWindow::dispose menufloatingwindow.cxx 134 0x7fffbf4bd766
    10 VclReferenceBase::disposeOnce vclreferencebase.cxx 39 0x7fffbf7520d9
    11 VclPtr<vcl::Window>::disposeAndClear vclptr.hxx 207 0x7fffbf3f98d2
    12 PopupMenu::ImplExecute menu.cxx 2947 0x7fffbf4a0ee7
    13 PopupMenu::Execute menu.cxx 2834 0x7fffbf49c392
    14 MenuButton::ExecuteMenu menubtn.cxx 77 0x7fffbf639f1d
    15 MenuButton::MouseButtonDown menubtn.cxx 214 0x7fffbf63a847
    16 ImplHandleMouseEvent winproc.cxx 708 0x7fffbf57ca27
    17 ImplHandleSalMouseButtonDown winproc.cxx 2338 0x7fffbf57e1af
    18 ImplWindowFrameProc winproc.cxx 2683 0x7fffbf57fc07
    19 SalFrame::CallCallback salframe.hxx 312 0x7fffbf3443c6
    20 ImplHandleMouseMsg salframe.cxx 3415 0x7fffbc818e8f
    ... <More>

However, the Menu that actually owns the accessible may
still be alive, and then opening the menu again results
in an attempt to make use of the already disposed object,
triggering a crash due to a DisposedException being thrown:

    1   RaiseException                                            KERNELBASE                           0x7ff808e8b699
    2   CxxThrowException                                         VCRUNTIME140                         0x7fffef535267
    3   comphelper::OCommonAccessibleComponent::ensureAlive       accessiblecomponenthelper.cxx   141  0x7fffdb8d1937
    4   comphelper::OContextEntryGuard::OContextEntryGuard        accessiblecontexthelper.hxx     64   0x7fffbf2fb8eb
    5   comphelper::OExternalLockGuard::OExternalLockGuard        accessiblecontexthelper.hxx     81   0x7fffbf2fb948
    6   OAccessibleMenuBaseComponent::getAccessibleContext        accessiblemenubasecomponent.cxx 641  0x7fffbf301337
    7   VCLXAccessibleComponent::ProcessWindowChildEvent          vclxaccessiblecomponent.cxx     165  0x7fffc0a9596d
    8   VCLXAccessibleComponent::WindowChildEventListener         vclxaccessiblecomponent.cxx     124  0x7fffc0a96669
    9   VCLXAccessibleComponent::LinkStubWindowChildEventListener vclxaccessiblecomponent.cxx     114  0x7fffc0a957f6
    10  Link<VclWindowEvent &,void>::Call                         link.hxx                        111  0x7fffbf45f7d3
    11  vcl::Window::CallEventListeners                           event.cxx                       300  0x7fffbf45fe0c
    12  vcl::Window::ImplSetReallyVisible                         window.cxx                      1331 0x7fffbf566bad
    13  vcl::Window::ImplSetReallyVisible                         window.cxx                      1344 0x7fffbf566c7d
    14  vcl::Window::Show                                         window.cxx                      2336 0x7fffbf56a8d1
    15  vcl::Window::Show                                         window.cxx                      2349 0x7fffbf56a9ce
    16  FloatingWindow::StartPopupMode                            floatwin.cxx                    825  0x7fffbf46a702
    17  PopupMenu::Run                                            menu.cxx                        3018 0x7fffbf4a6f02
    18  PopupMenu::ImplExecute                                    menu.cxx                        3005 0x7fffbf4a1707
    19  PopupMenu::Execute                                        menu.cxx                        2834 0x7fffbf49c392
    20  MenuButton::ExecuteMenu                                   menubtn.cxx                     77   0x7fffbf639f1d
    ... <More>

To fix that, adjust winaccessibility's
AccTopWindowListener to no longer just use
the VCLXWindow for the accessible, but
get the vcl::Window for the VCLXWindow and
query it's actual XAccessible using
vcl::Window::GetAccessible().

This fixes the tdf#164093 crash. The problem of
tdf#157001 where items in the popup menu of Calc's organize
template dialog are only announced the first time the menu
is opened still remains for now, but is also somehow
related to the MenuFloatingWindow being disposed.
(No longer reproducible when no longer calling
the base class FloatingWindow::dispose from
MenuFloatingWindow::dispose in a local test,
still needs further analysis.)

Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177889
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-05 20:12:40 +01:00
..
inc tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible 2024-12-05 20:12:40 +01:00
source tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible 2024-12-05 20:12:40 +01:00
CustomTarget_ia2_idl.mk makefile simplification: replace $(call gb_UnpackedTarball_get_dir,foo) 2024-05-06 11:40:45 +02:00
Library_uacccom.mk wina11y: Merge CAccComponent{,Base} 2024-09-17 07:51:14 +02:00
Library_winaccessibility.mk
Makefile
Module_winaccessibility.mk
README.md Fix typo 2024-10-19 15:52:43 +02:00
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 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