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 !

> 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 ?

Suggestion for a workaround
---------------------------

By reworking my own code, I can manage the list of buttons with the com.sun.star.comp.framework.LayoutManager and derivatives.

However I could not find a way to identify the coordinates of the pushed button. OTOH a click on a button currently does not pass any event structure (simply a zero integer value) to the invoked routine.
Would it be feasible to pass a structure identical or similar to a com.sun.star.awt.MouseEvent ? In particular, containing the X and Y coordinates of the mouse click vs. the parent toolbar position ?

What do you think ?

(In reply to Jean-Pierre Ledure from comment #9)
> Suggestion for a workaround
> ---------------------------
> 
> By reworking my own code, I can manage the list of buttons with the
> com.sun.star.comp.framework.LayoutManager and derivatives.

Great, thanks for looking into this!

Does this mean you now have a potential alternative to get the information that the

	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

logic mentioned in the initial comment was referring to?


> However I could not find a way to identify the coordinates of the pushed
> button.

Is the challenge finding the coordinates of a known button in general, or related to the pushed button in particular?

Do you have any UNO interface (X...) for the underlying button object, or only some name/text retrieved from the resource associated with the button?

Since you mention com.sun.star.comp.framework.LayoutManager: Do you possibly have a com::sun::star::ui::XUIElement reference from which you can retrieve a com::sun::star::awt::XWindow reference of the corresponding button, or is only the toolbar available that way?
(If you can get an XWindow, XWindow::getPosSize might be helpful to get the coordinates.)


> OTOH a click on a button currently does not pass any event structure
> (simply a zero integer value) to the invoked routine.
> Would it be feasible to pass a structure identical or similar to a
> com.sun.star.awt.MouseEvent ? In particular, containing the X and Y
> coordinates of the mouse click vs. the parent toolbar position ?

Can you possibly give a bit more detail on how that was implemented so far using the accessibility API, and how you register for the event you mention (that's apparently missing relevant information)?

As I said, I'm not an expert when it comes to scripting, but with a bit more details on

* how it was done so far
* what is the part for which you already have a potential alternative (ideally with corresponding code)
* what is the still missing part

, I can try to also think a bit more about potential ways to achieve that.

(In reply to Michael Weghorn from comment #6)
> 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.

I just tried this on current master (as of 7b5b9a5f08a69029594c45ba06edb249d0a11ba1), and that indeed works in a quick test. Updated sample code:

    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.getProperty("XAccessible")		'	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



The only change to the code in the initial description is changing

    accessiblecontext = element.RealInterface.AccessibleContext

to

    accessiblecontext = element.RealInterface.getProperty("XAccessible")

But as I said earlier, that can still break again later as a11y API is subject to change, so if there's a better solution, I wouldn't recommend going with this temporary workaround.

(In reply to Michael Weghorn from comment #10)

> Does this mean you now have a potential alternative to 
>  	accessiblecontext = element.RealInterface.AccessibleContext	

Yes, partially, I can derive the buttons names from the settings

> Is the challenge finding the coordinates of a known button in general, or
> related to the pushed button in particular?

Actually a script receives the X, Y, Width, Height values for any button. However, in se, this info is not very useful. Except when a button is clicked, activates a script, and a popup menu or alike is desired.
That's why I proposed in comment#9 to pass to the script a MouseEvent argument.
This would be an IMHO acceptable incompatibility between LO releases: easy to explain and to fix in existing scripts.

> Do you have any UNO interface (X...) for the underlying button object, or
> only some name/text retrieved from the resource associated with the button?
> 
> Since you mention com.sun.star.comp.framework.LayoutManager: Do you possibly
> have a com::sun::star::ui::XUIElement reference from which you can retrieve
> a com::sun::star::awt::XWindow reference of the corresponding button, or is
> only the toolbar available that way?

TBC ?

> (If you can get an XWindow, XWindow::getPosSize might be helpful to get the
> coordinates.)

>     accessiblecontext = element.RealInterface.getProperty("XAccessible")

This is great news. However it works fine in LO 26.2, but not in LO 25.8.

I tried
      accessiblecontext = element.RealInterface.AccessibleContext.AccessibleParent.AccessibleContext.getAccessibleChild(1)

where (1) is hardcoded (should be computed in reality) being the index in the layoutmanager.XUIElements array related to the concerned toolbar.
This works fine in LO 25.8, but not in LO 26.2.

=> To bypass the current blocking, I can prepare a patch in ScriptForge code with a few specific lines of code depending on the LO versions: <= 25.2, 25.8, >= 26.2

Better idea ?

(In reply to Jean-Pierre Ledure from comment #12)
> Actually a script receives the X, Y, Width, Height values for any button.
> However, in se, this info is not very useful. Except when a button is
> clicked, activates a script, and a popup menu or alike is desired.
> That's why I proposed in comment#9 to pass to the script a MouseEvent
> argument.
> This would be an IMHO acceptable incompatibility between LO releases: easy
> to explain and to fix in existing scripts.

Thanks for the additional explanation. It's currently still not fully clear to me how the script hooks up to the events of the buttons, though.

> > Do you have any UNO interface (X...) for the underlying button object, or
> > only some name/text retrieved from the resource associated with the button?
> > 
> > Since you mention com.sun.star.comp.framework.LayoutManager: Do you possibly
> > have a com::sun::star::ui::XUIElement reference from which you can retrieve
> > a com::sun::star::awt::XWindow reference of the corresponding button, or is
> > only the toolbar available that way?
> 
> TBC ?

What do you mean by this? Are you planning to give more details or expecting further info from my side?



(In reply to Jean-Pierre Ledure from comment #13)
> >     accessiblecontext = element.RealInterface.getProperty("XAccessible")
> 
> This is great news. However it works fine in LO 26.2, but not in LO 25.8.
> 
> I tried
>       accessiblecontext =
> element.RealInterface.AccessibleContext.AccessibleParent.AccessibleContext.
> getAccessibleChild(1)
> 
> where (1) is hardcoded (should be computed in reality) being the index in
> the layoutmanager.XUIElements array related to the concerned toolbar.
> This works fine in LO 25.8, but not in LO 26.2.
> 
> => To bypass the current blocking, I can prepare a patch in ScriptForge code
> with a few specific lines of code depending on the LO versions: <= 25.2,
> 25.8, >= 26.2

Quoting from my comment 6:

"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."

If sticking to the a11y logic, either having different code for LO 25.8 and master in ScriptForge or backporting a LO commit to 25.8 could be potential ways forward.

Does ScriptForge need to be compatible with multiple LO versions at the same time, or is each ScriptForge version tied to a LibreOffice version?
(I thought that ScriptForge by now gets bundled with LibreOffice, i.e. is tied to that version. In that case: Wouldn't it be fine for the ScriptForge code of each version to also be specific for a particular version?)


> Better idea ?

This should work for now, but as I mentioned, UNO a11y API is subject to change, so I wouldn't rely on that in the longer run.

Another potential approach I could think of is using the UNO API used by UI tests, similar to what 

    commit 864904e8d04fadb905dc9e22326a7bf0f69d38c7
    Author: Michael Weghorn
    Date:   Mon May 26 08:56:43 2025 +0200

        sw uitest: Port tdf146145 away from using a11y API

did to port an existing UI test away from using UNO a11y API (s. commit message for more details).

That UITest UNO API is also unpublished, but it at least doesn't depend on a11y implementation details any more and will likely stay around for now, as it's used in our own UI tests that need to access details about VCL windows (which is exactly what ScriptForge seems to be doing here as well).

It also still suffers from the problem mentioned in comment 7, however.

As far as I understand, this demo should be doing something similar to your example from the initial description, but using the UITest UNO API:

    Sub Main
        Dim I as long
        Dim windows as Object
        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


        uitest = GetProcessServiceManager().CreateInstance("org.libreoffice.uitest.UITest")
        toolbarUiObject = uitest.getWindow(element.RealInterface)
        toolbarItems = toolbarUIObject.getChildren()

        For i = 0 To UBound(toolbarItems)
            childId = toolbarItems(i)
            ' filter: only consider the toolbar item children; their ID starts with "toolboxitem-"
            prefix = "toolboxitem-"
            If Left(childId, Len(prefix)) = prefix Then
                toolbarItem = toolbarUiObject.getChild(childId)
                state = toolbarItem.getState()
                For j = 0 To UBound(state)
                    property = state(j)
                    If property.Name = "Text" Then
                        print property.Value
                    EndIf
                    Next
            EndIf
            Next
    End Sub

As far as I can see, position/size of the items is currently not available that way, but that could be added (in ToolBoxItemUIObject::get_state), e.g. by adding a "Rect" property (similar to the "Text" one used in the above example) or something like that.

Does that sound like a better potential approach/workaround for now?
(Due to the nature of depending on implementation details and unpublished UNO API, that approach may still require adjustments in ScriptForge in the future as well and there's no guarantee it will keep working, but not depending on a11y details would in my opinion be a step forward.)

@Xisco: Any thoughts on whether using the UITest API from ScriptForge for this purpose would be OK?

(In reply to Michael Weghorn from comment #14)
> It's currently still not fully clear
> to me how the script hooks up to the events of the buttons, though.

Well, badly: there is no mean to identify the button.

> > TBC ?
> 
> What do you mean by this? Are you planning to give more details or expecting
> further info from my side?

I will investigate this.

> Does ScriptForge need to be compatible with multiple LO versions at the same
> time ?

No (except me sometimes ...).

> > Better idea ?
> 
> Another potential approach I could think of is using the UNO API used by UI
> tests, (...)
> As far as I can see, position/size of the items is currently not available
> that way, but that could be added (in ToolBoxItemUIObject::get_state), e.g.
> by adding a "Rect" property (similar to the "Text" one used in the above
> example) or something like that.
> 
> Does that sound like a better potential approach/workaround for now?

It is not better without the "Rect" property.
Otherwise, if there is a reasonable expectation to have a +/- stable UITests API for a foreseeable future, then we can give it a try.
What would be the delay ? We should provide a correction in a forthcoming 25.2 release. Note that I can make a patch as described in comment#13 within a week or so.

Tell me what your preference is.

Thanks for your comments.

> > Since you mention com.sun.star.comp.framework.LayoutManager: Do you possibly
> > have a com::sun::star::ui::XUIElement reference from which you can retrieve
> > a com::sun::star::awt::XWindow reference of the corresponding button, or is
> > only the toolbar available that way?
> 
> TBC ?
> 
> > (If you can get an XWindow, XWindow::getPosSize might be helpful to get the
> > coordinates.)

Only the toolbar is accessible that way.
I did not succeed in finding any XWindow object encompassing a toolbar button :(

(In reply to Jean-Pierre Ledure from comment #15)
> > Does that sound like a better potential approach/workaround for now?
> 
> It is not better without the "Rect" property.
> Otherwise, if there is a reasonable expectation to have a +/- stable UITests
> API for a foreseeable future, then we can give it a try.

Regarding UITest API stability, Xisco might possibly have more insights on that.

(In case of using UITest API, adding a UI test that uses this might be nice: Even if we don't necessarily guarantee stability, this will at least make clear when something changes + can remind of notifying you/the ScriptForge developers if that's the case.)

> Tell me what your preference is.

If that's a viable option for now, I'd prefer this instead of using a11y API, as I'm expecting to make more changes to a11y in the future.

> What would be the delay ? We should provide a correction in a forthcoming
> 25.2 release. Note that I can make a patch as described in comment#13 within
> a week or so.

https://gerrit.libreoffice.org/c/core/+/191456 is a demo for a potential implementation. If you're building LO from source, you could try whether you get all information as needed this way.

I went with 4 properties "X", "Y", "Width" and "Height" instead of "Rect", because the UITest code always uses OUString for the value, so I think having one property for each value might be nicer than having to encode the whole rect as one string + then parsing the single values from that again on the ScriptForge side. But what the best format would be is totally open for discussion, if that's the way we want to pursue.

One option could also be to implement the solution from comment 13 right away for master and 25-8, then switch to the UITest API based solution for master only once it's ready, without the need for it to be finished before the next 25.8 release.

(In reply to Michael Weghorn from comment #14)

> @Xisco: Any thoughts on whether using the UITest API from ScriptForge for
> this purpose would be OK?

Hi Michael,
I'm not aware of anything else using the UITest API other than the UItests themself.
Your change in https://gerrit.libreoffice.org/c/core/+/191456 makes sense to me and if merged, I don't think it's going to change in the future, so at least it's going to be stable on that regard
Regarding your question about whether using the UITest API from ScriptForge, I'm afraid I can't answer it... I'm not sure whether this is the best approach or if other approaches are desirable.

(In reply to Michael Weghorn from comment #17)

> One option could also be to implement the solution from comment#13 right
> away for master and 25-8, then switch to the UITest API based solution for
> master only once it's ready, without the need for it to be finished before
> the next 25.8 release.

+1

(In reply to Xisco Faulí from comment #18)
> Hi Michael,
> I'm not aware of anything else using the UITest API other than the UItests
> themself.
> Your change in https://gerrit.libreoffice.org/c/core/+/191456 makes sense to
> me and if merged, I don't think it's going to change in the future, so at
> least it's going to be stable on that regard
> Regarding your question about whether using the UITest API from ScriptForge,
> I'm afraid I can't answer it... I'm not sure whether this is the best
> approach or if other approaches are desirable.

@Xisco: Thanks for the feedback!
If you're not explicitly advising against using the UITest API, then I think that it is at least a better alternative than using the a11y API if ScriptForge wants to continue accessing VCL implementation details for now.

(In reply to Jean-Pierre Ledure from comment #19)
> > One option could also be to implement the solution from comment#13 right
> > away for master and 25-8, then switch to the UITest API based solution for
> > master only once it's ready, without the need for it to be finished before
> > the next 25.8 release.
> 
> +1

Great, that sounds like we have a plan for the steps to take then.

@Jean-Pierre: Could you please check whether https://gerrit.libreoffice.org/c/core/+/191456 is all you need to switch from a11y API to the new approach or if anything else is missing? (whenever you get to it)

(In reply to Michael Weghorn from comment #20)
> @Jean-Pierre: Could you please check whether
> https://gerrit.libreoffice.org/c/core/+/191456 is all you need to switch
> from a11y API to the new approach or if anything else is missing? (whenever
> you get to it)
- the commit looks OK for me but I didn't test it yet.
- I will secure 25.8 (and master) first and adapt SF/master to the new approach in a 2nd step.

Thanks for help.

(In reply to Jean-Pierre Ledure from comment #21)
> - the commit looks OK for me but I didn't test it yet.
> - I will secure 25.8 (and master) first and adapt SF/master to the new
> approach in a 2nd step.

Perfect, thank you.

Jean-Pierre Ledure committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7420eb7b55fec40545cbda89167fca34f635b71f

ScriptForge fix tdf#168409 AccessibleContext

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jean-Pierre Ledure committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/1c81dbad870c2befad699e14e3694d684cf3064d

ScriptForge fix tdf#168409 AccessibleContext

It will be available in 25.8.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jean-Pierre Ledure committed a patch related to this issue.
It has been pushed to "libreoffice-25-8-2":

https://git.libreoffice.org/core/commit/564adf18a56c5040a188fb5315b7db09a17779b9

ScriptForge fix tdf#168409 AccessibleContext

It will be available in 25.8.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.