summaryrefslogtreecommitdiff
path: root/winaccessibility/source
AgeCommit message (Collapse)Author
2024-12-19wina11y: Deduplicate 2 cases doing the sameMichael Weghorn
Change-Id: I1135434fa99d3accb230e379850bcb6651663260 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178829 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-19tdf#157001 wina11y: Remove popup menu with its childrenMichael Weghorn
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
2024-12-13a11y: Move VCLXAccessibleComponent from toolkit to vclMichael Weghorn
After commit 168512dce7f1f1453c045584d47bd78a0a6c73f7 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>
2024-12-05tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessibleMichael Weghorn
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>
2024-12-05wina11y: Use existing references + drop duplicate checksMichael Weghorn
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>
2024-12-05wina11y: Drop unnecessary exception handlingMichael Weghorn
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
2024-12-05wina11y: Drop duplicate variable + checkMichael Weghorn
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
2024-12-05wina11y: Drop special combobox handling in AccessBridgeHandleExistingWindowMichael Weghorn
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
2024-12-05wina11y: Drop always true bShow paramMichael Weghorn
Change-Id: I794e486b3e5e7d341a05cec20cc218dd2cd7e242 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177881 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-05wina11y: Replace condition by by assert in AccessBridgeHandleExistingWindowMichael Weghorn
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>
2024-12-05wina11y: Drop unnecessary cast to sal_uInt16Michael Weghorn
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
2024-11-10com::sun::star -> cssMike Kaganski
Change-Id: I890ec73e30d3cc6b210903ecee29431f3cb5f635 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175979 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-11-07[API CHANGE] a11y: Switch AccessibleRelationType to enumMichael Weghorn
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
2024-10-01wina11y: Drop duplicate handling for focusable stateMichael Weghorn
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 a241661862ef35774f560e4068a895dcaa6f2113 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
2024-10-01wina11y: Use enum class for navigation directionMichael Weghorn
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
2024-10-01wina11y: Drop unused definesMichael Weghorn
Change-Id: Ic16f46b19b3478069cc9bafb4e6605f9a88733d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174319 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-10-01wina11y: Drop unused includes + "using namespace"Michael Weghorn
Change-Id: I3006690efbedd75970eea34412392a36847db8d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174318 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-30wina11y: Drop "using namespace css::accessibility::AccessibleRole"Michael Weghorn
Change-Id: I7c801f3101b0d4ed642cab799d44da092faa3bc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174279 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-30wina11y: Bridge focusable state as isMichael Weghorn
Drop all the special-casing of particular (parent) roles etc. when considering whether or not to set the focusable state. Instead, fully rely on the AccessibleStateType::FOCUSABLE state as reported by the underlying XAccessibleContext and report the IAccessible/MSAA STATE_SYSTEM_FOCUSABLE state whenever the former is set. I tend to think that if this this change results in unexpected behavior, it is likely that issues should best be fixed in the underlying XAccessibleContext implementations rather than worked around in the Windows a11y bridge. Change-Id: I6e2eee3a9cbe779de3b3d349f23efc6a68a8344b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174278 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: Unify handling for editable/readonly state a bitMichael Weghorn
The LABEL, STATIC and NOTIFICATION roles are used for readonly text, so if the EDITABLE state were ever set on these, that should be fixed in the underlying XAccessibleContext implementation instead of special handling to always set the readonly state in the Windows a11y bridge. Therefore, rely on the EDITABLE state not being set for these in order to report the IAccessible/MSAA STATE_SYSTEM_READONLY like for the other roles handled here. Change-Id: Ie8398ad0186d57ebf92701ab3a2c0603b50f5a2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174277 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-30wina11y: Rename UNO_MSAA_UNMAPPING to MSAA_NO_STATEMichael Weghorn
... to make clear that this is a constant with no state set. Also, move the definition to the only source file where it's used. Change-Id: Iaaba8d7053f71c63caab57c2b692b8e5898d37cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174276 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: Drop always default AccObject::InsertChild pos paramMichael Weghorn
This `pos` param never gets passed explicitly, so is always the default `LAST_CHILD`. Therefore, drop the param completely to simplify this. Change-Id: I8f51fe58b47bb2f0c18a853c81b8b6c85d4a6602 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174275 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-30wina11y: Move AccObject::GetExpandedState logic to only callerMichael Weghorn
Change-Id: I5505abf795c1133b77b9c4ec7bb762401b9a3826 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174274 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: Simplify AccObject::GetExpandedStateMichael Weghorn
* Drop the `isExpandable` out param that's unused at the only call site. * Use a bool return value instead of an out param for the remaining `isExpandable`. Change-Id: I2a37f0fec752f5e8e802ec781acf49035b3fbf2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174273 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: sal_Bool -> boolMichael Weghorn
Change-Id: I348e293981bbaeec650a463c958c5e301a804422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174272 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: Simplify AccObject::GetMSAAStateFromUNO with early returnMichael Weghorn
Change-Id: Ieeb152ac6e6ba99758fad0d202cc74614871401a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174271 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-30wina11y: Drop "using namespace css::accessibility::AccessibleStateType"Michael Weghorn
Explicitly specifying the `AccessibleStateType` namespace makes the distinction between the UNO and the IAccessible2 states clearer. Change-Id: If8dba19fa716753b1b838377546c5c810e588e5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174270 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop CAccImage::GetXInterfaceMichael Weghorn
Just use the `m_xImage` member directly, as already happens just a few lines above. Change-Id: I00f7e871a2cb5eb301ba033944d8d529cc10bbae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173536 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Just assign the ReferenceMichael Weghorn
Change-Id: Ibe0e9f1c8c6838044355db987d08298b267bed64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173535 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Rename CAccImage::{pRXImg -> m_xImage}Michael Weghorn
Adhere to naming conventions to make clearer this is a class member, and a uno::Reference. Change-Id: I804bb66d88675d1f5e7e0ee31f9244db5abf0125 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173534 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Check reference in CAccHyperLink::get_startIndexMichael Weghorn
Check the reference is valid in this method as well, just like in all of the other API methods. Change-Id: Ibb1a6a8b290ffefc502966ed0372c4e421fe68fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173533 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Drop CAccHyperLink::GetXInterfaceMichael Weghorn
Just consistently use the `m_xHyperlink` member directly. Change-Id: If2ac4150b5b733005b916d0c5f11e8c711d95c7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173532 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Just assign the ReferenceMichael Weghorn
Change-Id: I8ca9cd55723b1775284b23e13db409fc5d47005c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173531 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Rename CAccHyperLink::{pRXLink -> m_xHyperlink}Michael Weghorn
Adhere to naming conventions to make clearer that this is a class member, and a `uno::Reference`. Change-Id: I29caf6ad2d0adcfca430df72c2638dbd4ee06f1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173530 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Drop CAccEditableText::GetXInterfaceMichael Weghorn
Be consistent and just use CAccEditableText::mxEditableText directly, as already happens in each of the methods just a few lines further up. Change-Id: I70637714623f0410a60778e7bc1f4b007e034ddf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173529 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Just assign the referenceMichael Weghorn
operator= knows what to do, no custom handling needed. Change-Id: I9a64cc371e5b14c146e311364d1b4212d519d746 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173528 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Rename CAccEditableText::{pRXEdtTxt -> m_xEditableText}Michael Weghorn
Adhere to naming conventions and use a less cryptic name. Change-Id: I13ff9f515351fbbf0c749522edfb739e15626a67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173527 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: clang-format CAccEditableText sourcesMichael Weghorn
This in particular ensures that try/catch blocks are indented by an additional level, improving readability. Change-Id: I7fd538434bd8edb5748bb551fdfd2d4966293bd3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173526 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop CAccValue::GetXInterfaceMichael Weghorn
Be consistent and just use the `m_xValue` member directly, as is already done elsewhere in the same methods. Change-Id: I9b7a1e91cbe224115863cde9bb8d4fed14448436 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173447 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Prefix and rename CAccValue memberMichael Weghorn
Use m_ and x prefixes, as it's a class member and a uno::Reference. Change-Id: I3b345749c256bccb3c6c59b54eed4db8f38c5a7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173446 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Merge CAccComponent{,Base}Michael Weghorn
Merge the `CAccComponentBase` class into its only subclass `CAccComponent`. While at it, make the `m_xComponent` member private, which was previously protected for no reason anyway. Change-Id: I029348c51aefd1b7cdc3db68bac6abc31de15d61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173445 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: clang-format AccComponent.hMichael Weghorn
... in preparation of merging `CAccComponent` and `CAccComponentBase`. Change-Id: Ic7f436ec1bf1d4cbebfe27e86a29710719a33785 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173444 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop CAccComponentBase::GetXInterfaceMichael Weghorn
Just use the `m_xComponent` member directly, as already happens elsewhere in these methods. Change-Id: I1f3020e568d0d9b29576d0f446dea2f159119880 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173443 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Use standard naming prefixes in CAccComponentBaseMichael Weghorn
Use an `m_ ` prefix because it's a class member, and `x` because it's a uno::Reference. Change-Id: I084f41f4bca97b39d3bf365dd9025b0a9d145d24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173442 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop "//special query" commentsMichael Weghorn
It's unclear to me what these //special query comments above the null checks refer to and I find them more confusing than helpful. Remove them. Change-Id: I3a3d886a664d03ec37085e2f074928c2a3055820 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173441 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-17wina11y: Just assign the referenceMichael Weghorn
No need to manually use the pointer, and have special handling for an empty Reference. Change-Id: I414cfdccacecc79594c0bc5b57d782ea98b811fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173440 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop unused CAccComponentBase::grabFocusMichael Weghorn
Accessible's `IAccessibleComponent` interface [1] has no `grabFocus` method and `CAccComponentBase::grabFocus`. Therefore, drop it. The `IAccessible` interface has an `IAccessible::accSelect` method that can be used to request focus by passing the `SELFLAG_TAKEFOCUS` flag [3], but that is implemented in `CMAccessible::accSelect`. [1] https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_component.html#a8709fdbf3f51ae079af274854a8bffd4 [2] https://learn.microsoft.com/en-us/windows/win32/api/oleacc/nf-oleacc-iaccessible-accselect [3] https://learn.microsoft.com/en-us/windows/win32/winauto/selflag Change-Id: I1ae99fdbf60aa18a041c086a73f9bd7c6a80cace Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173439 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-17wina11y: Drop unused CAccComponentBase::get_locationOnScreenMichael Weghorn
While IAccessible's `IAccessibleComponent` interface [1] has a `get_locationInParent` method and the implementation in `CAccComponent::get_locationInParent` calls the base class one, `CAccComponentBase::get_locationInParent`, there is no `IAccessibleComponent::get_locationOnScreen` equivalent, and `CAccComponentBase::get_locationOnScreen` is simply unused. Therefore, drop it. The `IAccessible` interface has a `IAccessible::accLocation` method to return the location on screen, but that is implemented in `CMAccessible::accLocation`. Therefore, drop `CAccComponentBase::get_locationOnScreen`. [1] https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_component.html#a8709fdbf3f51ae079af274854a8bffd4 [2] https://learn.microsoft.com/en-us/windows/win32/api/oleacc/nf-oleacc-iaccessible-acclocation Change-Id: I1a38844101b4eca10afdc6356c46156ad2091f82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173438 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-09-12tdf#91739 wina11y: Create AccObject for parent as necessaryMichael Weghorn
In `AccObjectWinManager::InsertAccObj`, when no HWND was explicitly passed, it is attempted to retrieve the HWND from the parent's `AccObject`. If no parent AccObject exists yet, create/insert that one first. This fixes the following assert seen when using NVDA's SayAll feature to read the whole document with sample document mentioned in NVDA issue [1], also attached as attachment 196385 in tdf#91739 for reference: Assertion failed: pIAccessible && "Couldn't retrieve IAccessible object for relation target.", file C:/tools/cygwin/home/user/development/git/libreoffice/winaccessibility/source/UAccCOM/MAccessible.cxx, line 2755 It's also reproducible when manually trying to get the next flows-to relation target via NVDA's Python console when the first cell in the table has focus: >>> focus.flowsTo The issue is not reproducible when focus had been in the second cell before, as an accessible object has already been created otherwise in that case. Backtrace: 1 abort ucrtbase 0x7fff3b72286e 2 get_wpgmptr ucrtbase 0x7fff3b7241b5 3 wassert ucrtbase 0x7fff3b7244f1 4 CMAccessible::get_relationTargetsOfType MAccessible.cxx 2755 0x7fff1e028729 5 NdrSendReceive RPCRT4 0x7fff3d4ca2d3 6 NdrStubCall2 RPCRT4 0x7fff3d4625a7 7 CStdStubBuffer_Invoke combase 0x7fff3cfbc4ac 8 RoGetAgileReference combase 0x7fff3cf669c3 9 RoGetAgileReference combase 0x7fff3cf6674e 10 HSTRING_UserSize combase 0x7fff3cfbefb6 11 DllGetClassObject combase 0x7fff3cf470b3 12 CoWaitForMultipleHandles combase 0x7fff3cf6774d 13 RoGetActivatableClassRegistration combase 0x7fff3cf2eb26 14 CoGetMarshalSizeMax combase 0x7fff3cf5cfba 15 CallWindowProcW USER32 0x7fff3ccbef5c 16 DispatchMessageW USER32 0x7fff3ccbe684 17 ImplSalDispatchMessage salinst.cxx 475 0x7ffed452d378 18 ImplSalYield salinst.cxx 552 0x7ffed452da9d 19 WinSalInstance::DoYield salinst.cxx 581 0x7ffed452cfa1 20 ImplYield svapp.cxx 385 0x7ffed78befc4 21 Application::Yield svapp.cxx 474 0x7ffed78c2cd2 22 Application::Execute svapp.cxx 361 0x7ffed78bc656 23 desktop::Desktop::Main app.cxx 1691 0x7ffeecf689b7 24 ImplSVMain svmain.cxx 228 0x7ffed78d3d4c 25 SVMain svmain.cxx 261 0x7ffed78d45a2 26 soffice_main sofficemain.cxx 121 0x7ffeecfb9064 27 sal_main main.c 51 0x7ff782681013 28 main main.c 49 0x7ff78268105a 29 __scrt_common_main_seh exe_common.inl 288 0x7ff782681344 30 BaseThreadInitThunk KERNEL32 0x7fff3bb07374 31 RtlUserThreadStart ntdll 0x7fff3d85cc91 [1] https://github.com/nvaccess/nvda/issues/8152#issuecomment-2342167620 Change-Id: I246251f06d1885e0da96600ffc7dd0549854382f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173224 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins
2024-09-12wina11y: Drop superfluous AccObject::m_pIMAcc null checksMichael Weghorn
The `AccObject` ctor already asserts it's non-null, so there's no need to check again in various places. Change-Id: Ibba363d326198a89e391a4da54cff25c95eef776 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173223 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins