Description: Exploring the buttons belonging to a toolbar by macro code returns no button. There is no difference between toolbars stored in the document or stored at LO level. Running the code below returned a list of buttons in 25.2. The list is empty in 25.8. Steps to Reproduce: 1. Create a new empty Calc document 2. With the Basic IDE, enter next code in an empty Basic module: Sub Main With GlobalScope.BasicLibraries .loadLibrary("ScriptForge") If .hasByName("XrayTool") Then .loadLibrary("XrayTool") End With doc = CreateScriptService("Calc", ThisComponent) ' ScriptForge (Basic) object toolbar = doc.Toolbars("standardbar") ' ScriptForge (Basic) object toolbar.Visible = True layoutmanager = toolbar._LayoutManager ' com.sun.star.comp.framework.LayoutManager resourceURL = toolbar.ResourceURL ' private:resource/toolbar/standardbar element = layoutmanager.getElement(resourceURL) ' com.sun.star.ui.XUIElement accessiblecontext = element.RealInterface.AccessibleContext ' com.sun.star.accessibility.XAccessibleContext settings = element.getSettings(True) ' com.sun.star.container.XIndexAccess For i = 0 To accessiblecontext.AccessibleChildCount - 1 print accessiblecontext.getAccessibleChild(i).AccessibleName, Next i End Sub 3. Run the code Actual Results: No output. Expected Results: A message box should be displayed with the list of the names of the buttons in the "Standard" toolbar. Reproducible: Always User Profile Reset: No Additional Info: Actual release: Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 6; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: fr-BE (en_US.UTF-8); UI: en-US Calc: threaded The accessiblecontext.AccessibleChildCount value is zero. The behaviour is OK in next release: Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022 CPU threads: 6; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: fr-BE (en_US.UTF-8); UI: en-US Calc: threaded The accessiblecontext.AccessibleChildCount value is identical with the settings.Count property.
COnfirm. Working with Version: 25.2.5.0.0+ (X86_64) / LibreOffice Community Build ID: 1533b7de758d28ec08f4859f921b2edf894e87e4 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Not working with Version: 25.8.0.4 (X86_64) Build ID: 48f00303701489684e67c38c28aff00cd5929e67 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Michael, can you please take a look here? author Michael Weghorn <m.weghorn@posteo.de> 2025-05-26 09:08:41 +0200 committer Michael Weghorn <m.weghorn@posteo.de> 2025-05-28 09:19:59 +0200 commit 05591f072f752ae24de271ed5a96e0fc91440a6e (patch) tree e4a551483852ea5231ee1af57dcc67c7cf7f0893 parent 864904e8d04fadb905dc9e22326a7bf0f69d38c7 (diff) vcl a11y: Let ToolBox create its accessible directly This is the ToolBox equivalent of commit f82aac71ede9c3f2dc059ca4c8b24f60e0841933 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Thu May 22 12:30:12 2025 +0200 vcl a11y: Let PushButton create its accessible directly , see that commit's message for more background. Change-Id: Ib6a6746f7fcbcacddc4cc05a00cf63fe04407f80 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185688 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Michael, I added you here after I posted a regression message. Please take a look. Thanks.
(In reply to Jean-Pierre Ledure from comment #0) > accessiblecontext = element.RealInterface.AccessibleContext ' > com.sun.star.accessibility.XAccessibleContext > [...] > > The > accessiblecontext.AccessibleChildCount > value is identical with the > settings.Count > property. Please note that the accessibility UNO API is unpublished and for LibreOffice-internal use only and subject to change by design. It is not meant to be used by third party code like macros or extensions, so anything that relies on it never had any guarantee to keep working. Quoting from the commit message of f82aac71ede9c3f2dc059ca4c8b24f60e0841933 - the commit mentioned in comment 2: > According to the discussion in [1], there might be third-party > code (unrelated to a11y except for using UNO a11y API) also > relying on the assumption that the vcl::Window's XAccessible > is its VCLXWindow, but the UNO a11y API is an internal > implementation detail explicitly unpublished in > > commit 70626249cd247d9acdad417b8eaf252bae22c059 > Date: Thu Nov 29 00:27:03 2012 +0100 > > API CHANGE a11y unpublishing and add/removeListener rename. > > and has no stability guarantuee whatsoever and is therefore > not meant to be used by external users. If any third-party > code was relying on this implementation detail, it should be > ported away from relying on UNO a11y API. I'm sorry to say that, but this is an intentional change in the context of refactoring accessibility code to better fulfill it's actual purpose (support assistive technology via the platform accessibility protocols) and increase code maintainability. Please try to find an alternative to using the UNO accessibility API - and feel free to create a new feature request (with clear requirements + use case) in case you're missing specific API.
(In reply to Michael Weghorn from comment #4) > > Please note that the accessibility UNO API is unpublished and for > LibreOffice-internal use only and subject to change by design. It is not > meant to be used by third party code like macros or extensions, so anything > that relies on it never had any guarantee to keep working. Hmm ... Can you give pointers to that statement ? (https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1accessibility_1_1AccessibleContext.html is silent about such a limitation.) > I'm sorry to say that, but this is an intentional change in the context of > refactoring accessibility code to better fulfill it's actual purpose > (support assistive technology via the platform accessibility protocols) and > increase code maintainability. I understand perfectly your intent. Note however that the release notes also are silent about this API change. > Please try to find an alternative to using the UNO accessibility API - and > feel free to create a new feature request (with clear requirements + use > case) in case you're missing specific API. As a use case, consider next example that ran smoothly in LO 25.2 and before, and aborts in LO 25.8: https://gitlab.com/LibreOfficiant/scriptforge/-/snippets/4874248 The demand is simply: which are the (push)buttons in a toolbar, their coordinates and the commands associated with a click ? Is this stored elsewhere in a UNO instance ? Thanks for helping me to find a workaround. PS: I cannot agree with the actual status (RESOLVED/NOTABUG) of this bug report and feel free to reopen it later if no workaround is feasible.
(In reply to Jean-Pierre Ledure from comment #5) > > Please note that the accessibility UNO API is unpublished and for > > LibreOffice-internal use only and subject to change by design. It is not > > meant to be used by third party code like macros or extensions, so anything > > that relies on it never had any guarantee to keep working. > > Hmm ... Can you give pointers to that statement ? Commit that explicitly unpublished UNO accessibility API: https://git.libreoffice.org/core/+/70626249cd247d9acdad417b8eaf252bae22c059 There is a corresponding release note entry for 4.0 ( https://wiki.documentfoundation.org/ReleaseNotes/4.0 ). Quoting from that one: > * Deprecation and un-publishing of internal accessibility API > * This API was primarily used internally for our bridge implementations to native accessibility technology APIs, and will need adapting in future. > > The following UNO services and interfaces are no longer published: > [long list of all UNO a11y interfaces and services] (In reply to Jean-Pierre Ledure from comment #5) > (https://api.libreoffice.org/docs/idl/ref/ > servicecom_1_1sun_1_1star_1_1accessibility_1_1AccessibleContext.html is > silent about such a limitation.) In general, any API that is not marked as "published" is unpublished and considered for internal use. See also tdf#163747 for more details. Unfortunately, the distinction apparently hasn't been clear to many users of the API in practice. (We generally try to avoid changing even unpublished API "for no reason" if there is a fair chance of it being used in practice, but I don't see keeping UNO a11y API as something feasible going forward. Those uses of the API I have become aware of so far were actually unrelated to the intention of the API, i.e. not directly related to accessibility in the first place.) > I understand perfectly your intent. > Note however that the release notes also are silent about this API change. See above for the corresponding release note entry for 4.0 when the API was unpublished. (For what it's worth: Technically, the commit mentioned in comment 2 also didn't change the API itself, only the implementation detail on what object implements the relevant logic, with further changes done in later commits.) > > Please try to find an alternative to using the UNO accessibility API - and > > feel free to create a new feature request (with clear requirements + use > > case) in case you're missing specific API. > > As a use case, consider next example that ran smoothly in LO 25.2 and > before, and aborts in LO 25.8: > https://gitlab.com/LibreOfficiant/scriptforge/-/snippets/4874248 > The demand is simply: which are the (push)buttons in a toolbar, their > coordinates and the commands associated with a click ? > Is this stored elsewhere in a UNO instance ? I'm not particularly familiar with extension or macro development and don't have any particular API in mind. > Thanks for helping me to find a workaround. For the current development version (git master), what could possibly work as a temporary workaround is using the same approach that the Java accessibility tests currently use to get access to the XAccessible/XAccessibleContext by using the deprecated XVclWindowPeer interface and its XVclWindowPeer::getProperty method to request the "XAccessible" property, see commit d1a25112bbbe3eb8e1c86840cb853e1694ec96ba Author: Michael Weghorn Date: Wed Jun 18 17:49:48 2025 +0200 java a11y tests: Don't rely on XWindow being XAccessible and its commit message for more details. But please be aware that this can only be seen as a temporary workaround, as that would still rely on accessibility implementation details that are subject to further changes in the future. As far as I can see, this commit is also not included in the 25-8 branch, but if such a temporary workaround is desirable for now to give more time for finding a better solution, making that approach available for 25.8 as well could be investigated. What do you think?
tdf#159966 is another example of a macro using a11y implementation details in an unsupported way, and which also mentions another general problem of that approach: It only works with vcl widgets, so will e.g. stop working for the GTK or Qt based VCL plugins on Linux once the toolbar starts using native GTK/Qt widgets.
(In reply to Michael Weghorn from comment #6) > In general, any API that is not marked as "published" is unpublished and > considered for internal use. > See also tdf#163747 for more details. > Unfortunately, the distinction apparently hasn't been clear to many users of > the API in practice. Indeed, new for me. > (We generally try to avoid changing even unpublished > API "for no reason" if there is a fair chance of it being used in practice, > but I don't see keeping UNO a11y API as something feasible going forward. > Those uses of the API I have become aware of so far were actually unrelated > to the intention of the API, i.e. not directly related to accessibility in > the first place.) I was curious and typed 'AccessibleContext' in the search box of https://forum.openoffice.org/en/forum/viewforum.php?f=19 => 109 matches ... > ... > But please be aware that this can only be seen as a temporary workaround, as > that would still rely on accessibility implementation details that are > subject to further changes in the future. > > As far as I can see, this commit is also not included in the 25-8 branch, > but if such a temporary workaround is desirable for now to give more time > for finding a better solution, making that approach available for 25.8 as > well could be investigated. First on master, afterwards, if successful, application on 25.8. > > What do you think? 1. I'm sure that, after your commits, the LO code is now better prepared for the future, but ... 2. A standard feature of LO is deeply broken: (https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03/sf_toolbarbutton.html?DbPAR=BASIC). The subcomponents of a toolbar cannot be read anymore with the so far used [UNO] interfaces. => A sustainable alternative should be found. 3. I reset the status of this bug report. 4. Thanks for your support !