Instead of passing an XAccessibleContext wrapped in a uno::Any,
pass the XAccessible. This drops an extra level of
wrapping/unwrapping.
The same will be done for XAccessibleGroupPosition::getObjectLink
in an upcoming commit.
Since the XAccessibleGroupPosition interface
(and the UNO a11y API in general) is unpublished
and meant for internal use only, changing it should
be unproblematic.
Change-Id: I5db3a99bb8d78099e3b136cbcd402fe2ae49d49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211216
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Window::GetAccessible returns an OAccessible. Use that
more specific type instead of the abstract XAccessible
UNO interface. OAccessible also implements the
XAccessibleContext interface itself, so there is no need
to request that one separately.
Change-Id: Ia40a9e5684ce321f0e5aff7ccd34bd3c488e1ab9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210437
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
At the only caller, a reference to the concrete implementation
class, MSAAServiceImpl, is available, so there is no need
to go via the UNO abstraction for this method call.
This also allows to switch the param to vcl::Window*, instead
of casting back and forth.
Drop the method from the unpublished UNO interface that
is only meant to be used internally to implement the
Windows a11y bridge.
Change-Id: I59033028ca31243ec350739fd9b078ddedc1cd34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201771
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
stack:
UAccCOM.dll!ATL::CComObjectRootBase::OuterAddRef() Line 2631
UAccCOM.dll!ATL::CComContainedObject<CAccImage>::AddRef() Line 3719
AccEventCache.dll!00007ffd2039be28()
AccEventCache.dll!00007ffd20355677()
AccEventCache.dll!00007ffd20346d41()
AccEventCache.dll!00007ffd20347f9a()
AccEventCache.dll!00007ffd20338ba2()
AccEventCache.dll!00007ffd20380dd8()
AccEventCache.dll!00007ffd2037fd7b()
AccEventCache.dll!00007ffd2037f7ee()
AccEventCache.dll!00007ffd2037d9e6()
AccEventCache.dll!00007ffd2037d07f()
^ JAWS
GlobalHooksDispatcher.dll!00007ffd214daed4()
GlobalHooksDispatcher.dll!00007ffd214d8d84()
user32.dll!00007ffd492068ac()
ntdll.dll!00007ffd4ae71424()
win32u.dll!NtUserNotifyWinEvent()
winaccessibility.dll!AccObjectWinManager::NotifyAccEvent(com::sun::star::accessibility::XAccessible * pXAcc, UnoMSAAEvent eEvent) Line 182
^ selfAccObj looks very dead here but that is a red herring!
winaccessibility.dll!AccContainerEventListener::FireStateFocusedChange(bool enable) Line 351
winaccessibility.dll!AccContainerEventListener::SetComponentState(__int64 state, bool enable) Line 178
winaccessibility.dll!AccParagraphEventListener::SetComponentState(__int64 state, bool enable) Line 123
winaccessibility.dll!AccContainerEventListener::HandleStateChangedEvent(com::sun::star::uno::Any oldValue, com::sun::star::uno::Any newValue) Line 106
winaccessibility.dll!AccContainerEventListener::notifyEvent(const com::sun::star::accessibility::AccessibleEventObject & aEvent) Line 72
winaccessibility.dll!AccParagraphEventListener::notifyEvent(const com::sun::star::accessibility::AccessibleEventObject & aEvent) Line 77
comphelper.dll!comphelper::AccessibleEventNotifier::addEvent(const unsigned long _nClient, const com::sun::star::accessibility::AccessibleEventObject & _rEvent) Line 256
swlo.dll!SwAccessibleContext::FireAccessibleEvent(com::sun::star::accessibility::AccessibleEventObject & rEvent) Line 457
swlo.dll!SwAccessibleContext::FireStateChangedEvent(__int64 nState, bool bNewState) Line 478
swlo.dll!SwAccessibleParagraph::InvalidateFocus_() Line 397
swlo.dll!SwAccessibleContext::InvalidateFocus() Line 1314
swlo.dll!SwAccessibleMap::InvalidateFocus() Line 2695
swlo.dll!SwViewShell::InvalidateAccessibleFocus() Line 2597
swlo.dll!SwEditWin::GetFocus() Line 5569
vcllo.dll!vcl::Window::CompatGetFocus() Line 3891
vcllo.dll!vcl::Window::ImplGrabFocus(GetFocusFlags nFlags) Line 385
vcllo.dll!vcl::Window::GrabFocus() Line 2983
sfxlo.dll!SfxFrame::GrabFocusOnComponent_Impl() Line 650
The problem is quite simply that CMAccessible::SmartQI() returns a
pointer that is the result of querying the newly created COM aggregation
for IID_IUnknown instead of the requested `iid` interface.
Apparently the wrong result happens to work in many cases, but the
CAccTable actually has 2 interfaces IAccessibleTable and
IAccessibleTable2, and the COM aggravation for IAccessibleTable2 is the
one that crashes; in this case the correct pointer is an offset of 8 to
the start of CAccTable, while in the working cases there is no offset.
So likely the bug was introduced by commits
3b86569fcb and
d0e8e6e3cd but only started to crash with
839dbf9ecf.
Change-Id: I7c7d295c8032b95fe7f64b8da4dd9bc3212563f9
(cherry picked from commit 9502a9f76731afa0f5105e6d79b069222677f88d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194730
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
The following commits introduced these:
77a39107b1 (Silence clang-cl -Wextra-tokens
in midl-generated code, 2015-11-28);
5ccdc4187b (Silence clang-cl -Wextra-tokens
in midl-generated code, 2015-11-30);
34604446fc (Various clang-cl/loplugin
warnings, 2017-03-14).
The problem was, that some versions of midl compiler generated an invalid
code like "#endif !_MIDL_USE_GUIDDEF_", which caused warnings in gcc and
clang (see e.g. https://stackoverflow.com/q/29153518/1397376).
I see that as of VS 2022, this problem is not reproducible, so let's drop
these.
Change-Id: Icce797ae6fa8b1aca17ca0b5051e2af606126bf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194010
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This in particular ensures that try blocks
are indented by an additional indentation
level as expected.
Change-Id: I1fa6c4f2a02f70aeabd8eee56749c636b79ba2bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192019
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is the Windows version of
Change-Id: Ieca9dff66eef366bf2a3845e5fdb53b3bfa70df9
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Aug 14 11:19:14 2025 +0200
tdf#167930 gtk3 a11y: Keep caret pos when removing selection
Change-Id: I3cc3fb781ffc036d7f4df4552aee766378fdb0c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189581
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use an OAccessible var instead of an XAccessible one, which
drops the need to query for the XAccessibleConetxt interface.
Change-Id: I331890f6d2b1d507ad72108a10538fabb1372cfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188606
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
By now, the accessible is known to always be an OAccessible,
so return that more specific type instead of a Reference to
the abstract XAccessible interface.
Change-Id: I60f6b2d6465abfcb04d4ee7d3a26bce69fccded3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188182
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
VCLXAccessibleComponent by now implements both,
the XAccessible and XAccessibleContext interfaces,
so calling VCLXAccessibleComponent::getAccessibleContext
(implemented in the OAccessibleComponentHelper base class)
is redundant.
Change-Id: I1cee73b042ec38612bee0cc97590d58faccb96d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185850
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
An assert failed in debugging, when closing print preview in Writer:
ucrtbased.dll!_wassert(const wchar_t * expression, const wchar_t * file_name, unsigned int line_number) Line 443
comphelper.dll!`anonymous namespace'::implLookupClient(const unsigned long nClient, std::_List_iterator<std::_List_val<std::_List_simple_types<std::pair<unsigned long const ,comphelper::OInterfaceContainerHelper4<com::sun::star::accessibility::XAccessibleEventListener>>>>> & rPos) Line 140
comphelper.dll!comphelper::AccessibleEventNotifier::removeEventListener(const unsigned long _nClient, const com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleEventListener> & _rxListener) Line 229
swlo.dll!SwAccessibleContext::removeAccessibleEventListener(const com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleEventListener> & xListener) Line 746
winaccessibility.dll!AccEventListener::RemoveMeFromBroadcaster(bool isNotifyDestroy) Line 262
winaccessibility.dll!AccEventListener::disposing(const com::sun::star::lang::EventObject & __formal) Line 287
comphelper.dll!comphelper::OInterfaceContainerHelper4<com::sun::star::accessibility::XAccessibleEventListener>::disposeAndClear(std::unique_lock<std::mutex> & rGuard, const com::sun::star::lang::EventObject & rEvt) Line 492
comphelper.dll!comphelper::AccessibleEventNotifier::revokeClientNotifyDisposing(const unsigned long _nClient, const com::sun::star::uno::Reference<com::sun::star::uno::XInterface> & _rxEventSource) Line 204
swlo.dll!SwAccessibleContext::Dispose(bool bRecursive, bool bCanSkipInvisible) Line 1050
swlo.dll!SwAccessibleMap::~SwAccessibleMap() Line 1571
swlo.dll!SwAccessibleMap::`scalar deleting destructor'(unsigned int)
swlo.dll!std::_Destroy_in_place<SwAccessibleMap>(SwAccessibleMap & _Obj) Line 324
swlo.dll!std::_Ref_count_obj2<SwAccessibleMap>::_Destroy() Line 2118
swlo.dll!std::_Ref_count_base::_Decref() Line 1161
swlo.dll!std::_Ptr_base<SwAccessibleMap>::_Decref() Line 1385
swlo.dll!std::shared_ptr<SwAccessibleMap>::~shared_ptr<SwAccessibleMap>() Line 1690
swlo.dll!std::shared_ptr<SwAccessibleMap>::reset() Line 1737
swlo.dll!SwViewShellImp::~SwViewShellImp() Line 108
swlo.dll!SwViewShellImp::`scalar deleting destructor'(unsigned int)
swlo.dll!std::default_delete<SwViewShellImp>::operator()(SwViewShellImp * _Ptr) Line 3309
swlo.dll!std::unique_ptr<SwViewShellImp,std::default_delete<SwViewShellImp>>::reset(SwViewShellImp * _Ptr) Line 3471
swlo.dll!SwViewShell::~SwViewShell() Line 324
swlo.dll!SwViewShell::`scalar deleting destructor'(unsigned int)
swlo.dll!SwPagePreview::~SwPagePreview() Line 1235
swlo.dll!SwPagePreview::`vector deleting destructor'(unsigned int)
sfxlo.dll!SfxViewFrame::SwitchToViewShell_Impl(unsigned short nViewIdOrNo, bool bIsIndex) Line 2690
SwAccessibleContext::Dispose called revokeClientNotifyDisposing,
which removed the SwAccessibleContext's id from its map, and then
called disposing() for all listenera of the SwAccessibleContext.
When one of the listeners, in its disposing(), tried to call
broadcaster's removeAccessibleEventListener, this violated the
API: XEventListener::disposing documentation directly prohibits
calling any methods of the broadcaster.
This was obviously a confusion, already present in commit
a18bdb3bc0 (Integrate branch of
IAccessible2, 2013-11-19), where the semantics of disposing()
was thought as "the listener is disposing", when in fact, it's
broadcaster notification about broadcaster's disposal.
Change-Id: Ib7f79b2214ffeedec6b4a4c75813e4ffa2d43270
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186242
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
While at the moment, the XAccessible for many vcl::Window
subclasses is a VCLXWindow, this is an implementation
detail that is subject to change.
Switch away from relying on that implementation detail,
and instead rely on the XAccessibleContext being a
VCLXAccessibleComponent, which will remain true even
if that one will be created without VCLXWindow being
involved in the future.
See also
commit b1f3e41f10
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed May 21 11:03:56 2025 +0200
sw a11y test: Don't rely on XWindow being XAccessible
for more background (which ports away from an assumption
"the other way around").
Change-Id: Ia2e2fe9d88c05afcde2c8a6d31c20c60cfbd5c49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185645
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In addition, rename `pRXI` according to naming scheme
(starting with `x` as it is an rtl::Reference).
Change-Id: Ib699957a35b3f49606c8196f5d7350cf27b71da9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184531
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
All XAccessibleExtendedAttributes::getExtendedAttributes
implementations return a OUString wrapped in an Any (or
an empty Any), and all consumers also expect that.
Therefore, change the return type from Any to OUString
to make that clearer and simpler.
Change-Id: Ic6af692f72fd072c4039996f31208ac2098d2750
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184514
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the unused `oldValue` param from the methods
handling the SELECTION_CHANGED_* events, and make
them non-virtual, as they don't need to be overriden
in any subclass.
Change-Id: Ic4a248a6dedaa0a6b25b22dd5673be2bb27a4fc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183791
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
* AccObjectWinManager::CreateAccEventListener always returns
non-empty reference, so replace if check by assert.
* Use "x" prefix for rtl::Reference.
* No need to explicitly have a uno::Reference<XAccessibleEventListener>,
just pass the rtl::Reference.
Change-Id: I0c45f70670a21dbd879c3e4c8c093f155722155a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183682
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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>
In AccTopWindowListener::windowClosed, drop the special
handling that was causing a popup menu (floating window)'s
accessible to not be removed from the objects that
the AccObjectWinManager manages.
It's unclear to me why that special handling was there
for accessibles with role
css::accessibility::AccessibleRole::POPUP_MENU, but might
have been some workaround for another issue fixed in the
meanwhile.
Removing the menu's children, but not the menu itself would
result in the menu's children not to be reinserted (and thus
no a11y listeners be registered) when the menu is shown again
after being closed, so that no focus events for the children
would be sent by the Windows a11y bridge.
Remove the menu's accessible as well and rely on the default
logic. This makes NVDA announce menu entries in Calc's
Organize Template menu also once the menu has been closed
and is then opened again.
Change-Id: Ie9cf96cad95215b9aeb0ebd7e4970da3c35b92c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178825
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
After
commit 168512dce7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 12 18:06:13 2024 +0100
a11y: Stop using VCLXWindow in vcl a11y classes
and further related commits, VCLXAccessibleComponent
no longer depends on anything in the toolkit module,
so move it from there to vcl.
This way, subclassing VCLXAccessibleComponent (as the
a11y classes for vcl widgets do, currently located in
accessibility/ ) no longer introduces a toolkit
dependency.
Change-Id: I4fd33fb1dc2265d75e8ca9ad87bcc70db61639d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178434
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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::star::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::star::accessibility::XAccessibleContext2,com::sun::star::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>
There's no need to have local raw pointer variables
in addition to the existing References.
Replace all uses of the former by using the latter
and drop duplicate checks.
Change-Id: I1339dabecbe8e1652e49df8ecd5ce2749b897f47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177888
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Window::GetSystemData should never throw an
exception, so there's no need for exception
handling here. Also, return early if the
system data is null.
Change-Id: I65794f10019d0c2fb5cc7150500b551c31cc2a08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177887
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
No need to have `pAccessibleContext` as a raw
pointer, just use the `xContext`. And that one
has already been checked for being a non-empty
Reference above.
Change-Id: I15d7e70ddbc8b260e5e1bc0eb4e190c54d6a2ea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177884
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It's unclear to me why the list child's accessible should
be passed instead of the window's here.
In addition, AccessBridgeHandleExistingWindow is only relevant
when the AT brigde is started, i.e. for example when starting
a screen reader while LO has been running already. This makes
this look even less relevant and unclear to me why special handling
would be applied for that case, but not when a combobox popup
is shown when a11y has been active before already.
Change-Id: Ie7b16de36889e2432f6ac9455ab297ca16d3b26e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177882
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The method only gets called from AccessBridgeUpdateOldTopWindows
which always passes a non-null window.
Change-Id: I7d6d4effb75c722af6176257b8f296b5a77734cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177880
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application::GetTopWindow also takes a tools::Long param,
so there's no reason to cast to sal_uInt16.
Change-Id: Ic592262bee8173329986ccb83298a26deb3586b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177879
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch css::accessibility::AccessibleRelationType
from integer constants to an enum.
This provides more type safety and improves the debugging
experience, e.g. GDB now prints
com::sun::star::accessibility::AccessibleRelationType::AccessibleRelationType_CONTENT_FLOWS_TO
instead of just "2" when printing the value of a
corresponding variable, so it's no longer necessary
to manually look up what constant has that integer
value to know what relation this refers to.
offapi/com/sun/star/accessibility/AccessibleRelationType.idl
had this comment:
> <p>We are using constants instead of a more typesafe enum. The reason
> for this is that IDL enums may not be extended. Therefore, in order to
> include future extensions to the set of roles we have to use constants
> here.</p>
However, the a11y UNO API is internal (not published),
so that shouldn't be a concern.
Change-Id: I44a7d56cb085dc24effb24fcd34bb222b78ef4cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176153
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When initializing the a11y bridge on Windows, no longer
check whether the screen reader parameter
`SPI_GETSCREENREADER` [1] is explicitly set or require
to explicitly enable by setting an
`SAL_FORCE_IACCESSIBLE2` environment variable.
For performance reasons, it of course makes sense to only
enable the a11y bridge when there is actually assistive
technology that makes use of it.
However, `ImplInitAccessBridge` already only gets called
when either support for assistive technology has explicitly
been enabled in the settings (i.e. in "Tools" -> "Options" -> "LibreOfficeDev"
-> "Accessibility", the "Support assistive technology tools (restart
required" checkbox was checked) or when a `WM_GETOBJECT` message
is received, whose documentation says [2]:
> Sent by both Microsoft Active Accessibility and Microsoft UI Automation
> to obtain information about an accessible object contained in a server
> application.
>
> Applications never send this message directly. Microsoft Active
> Accessibility sends this message in response to calls to
> AccessibleObjectFromPoint, AccessibleObjectFromEvent, or
> AccessibleObjectFromWindow. However, server applications handle this
> message. UI Automation sends this message in response to calls to
> IUIAutomation::ElementFromHandle, ElementFromPoint, and
> GetFocusedElement, and when handling events for which a client has
> registered.
Both of these cases (explicitly enabled, AT requests information) justify
enabling the a11y bridge by themselves, so drop the extra check.
Qt's UIA bridge for example also gets activated when a WM_GETOBJECT
message is received [3].
This makes both, Microsoft Narrator (screen reader shipped with
Windows, but which doesn't set the `SPI_GETSCREENREADER` parameter)
and Microsoft Accessibility Insights for Windows (a tool for a11y
analysis/debugging) work - at least to a certain degree - without
having to explicitly set the environment variable
`SAL_FORCE_IACCESSIBLE2`.
While LibreOffice doesn't have a UIA bridge at this point in time,
Windows provides an MSAA (IAccessible) to UIA proxy that provides
some basic information via UIA at least, see [4]:
> The LegacyIAccessible control pattern is supported by the Microsoft
> Active Accessibility to Microsoft UI Automation Proxy.
As expected, a breakpoint or assert in `ImplInitAccessBridge`
only got hit in my testing when either an AT was active or the
above-mentioned option was explicitly enabled, not otherwise when
starting or using LO.
[1] https://learn.microsoft.com/en-us/windows/win32/winauto/screen-reader-parameter
[2] https://learn.microsoft.com/en-us/windows/win32/winauto/wm-getobject
[3] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/windows/uiautomation/qwindowsuiaaccessibility.cpp?id=e9662a4b665144a5eca418925d331024ec71fa2c#n40
[4] https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-implementinglegacyiaccessible
Change-Id: Iddafb149b50771412ba59972d0401bada6a9f680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175172
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Setting the `isFocusable` var to true and
calling `IncreaseState` for the focusable state
further down is unnecessary, as that already happens
in the line just below the variable is set.
Therefore, drop this duplication.
In addition, the now dropped call to `IncreaseState`
should have used the UNO state, AccessibleStateType::FOCUSABLE
as well, not the IAccessible state, STATE_SYSTEM_FOCUSABLE,
as AccObject::IncreaseState takes the UNO state while
CMAccessible::IncreaseState (called by the former)
takes the IAccessible/MSAA state.
The switch from the UNO to the IAccessible2 state for
the param was accidently done in
commit a241661862
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Sep 30 13:37:14 2024 +0100
wina11y: Bridge focusable state as is
Change-Id: I4b3923897444fdc75b15fe2cd9e91ba5f405507e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174341
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the `DM_NIR` enum to an enum class
`NavigationDirection` and move it to MAccessible.{h,cxx}
which is the only place where it's used.
The param name of "flags" previously used in
CMAccessible::GetNavigateChildForDM was misleading,
as any of the values can only be handled exclusively.
Change-Id: I39d8d6afc5c8c845b3aa0add7bd314501f4c91b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174320
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Michael Weghorn