In recent weeks, JunitTest_toolkit_complex was seen occasionally
failing in CI, see e.g. last ESC minutes [1]:
> + tests that failed more than twice in last seven days
> [...]
> 18 JunitTest_toolkit_complex gerrit_linux_clang_dbgutil
It's unclear why the failure started to happen recently
and it doesn't happen reliably.
I was unable to reproduce the problem locally, even when running
make JunitTest_toolkit_complex
in a loop.
From a sample Jenkins failure log [2], what *might* be happening
is that the model etc. get disposed before the grid control in
the Java test code.
From the console log:
There were 6 failures:
1) testView(complex.toolkit.GridControl)
com.sun.star.lang.DisposedException
at com.sun.star.lib.uno.environments.remote.JobQueue.removeJob(JobQueue.java:199)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:309)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:279)
at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:83)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:619)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
at jdk.proxy2/jdk.proxy2.$Proxy21.dispose(Unknown Source)
at complex.toolkit.GridControl.impl_dispose(GridControl.java:79)
at complex.toolkit.GridControl.cleanupTestCase(GridControl.java:615)
... 35 trimmed
Caused by: java.io.EOFException
at java.base/java.io.DataInputStream.readInt(DataInputStream.java:386)
at com.sun.star.lib.uno.protocols.urp.urp.readBlock(urp.java:364)
at com.sun.star.lib.uno.protocols.urp.urp.readMessage(urp.java:96)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:92)
2) testSortableDataModel(complex.toolkit.GridControl)
com.sun.star.lang.DisposedException: java_remote_bridge com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge@210366b4 is disposed
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.checkDisposed(java_remote_bridge.java:689)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:603)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:145)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:129)
at jdk.proxy2/jdk.proxy2.$Proxy12.getServiceManager(Unknown Source)
at complex.toolkit.GridControl.createInstance(GridControl.java:654)
at complex.toolkit.GridControl.impl_recreateGridModel(GridControl.java:91)
at complex.toolkit.GridControl.testSortableDataModel(GridControl.java:354)
C++ backtrace:
Thread 1 (Thread 0x7f0aff59adc0 (LWP 2939300)):
#0 0x00007f0b0708d4bc in __pthread_kill_implementation () at /lib64/libc.so.6
#1 0x00007f0b0703fbb6 in raise () at /lib64/libc.so.6
#2 0x00007f0b07029873 in abort () at /lib64/libc.so.6
#3 0x00007f0b0786db51 in (anonymous namespace)::callSystemHandler(int, siginfo_t*, void*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libuno_sal.so.3
#4 0x00007f0b0786d680 in (anonymous namespace)::signalHandlerFunction(int, siginfo_t*, void*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libuno_sal.so.3
#5 0x00007f0b0703fc60 in <signal handler called> () at /lib64/libc.so.6
#6 0x00007f0b0708d4bc in __pthread_kill_implementation () at /lib64/libc.so.6
#7 0x00007f0b0703fbb6 in raise () at /lib64/libc.so.6
#8 0x00007f0b07029873 in abort () at /lib64/libc.so.6
#9 0x00007f0b0702979b in _nl_load_domain.cold () at /lib64/libc.so.6
#10 0x00007f0b070388f6 in () at /lib64/libc.so.6
#11 0x00007f0aff09e392 in com::sun::star::uno::Reference<com::sun::star::awt::grid::XMutableGridDataModel>::operator->() const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#12 0x00007f0aff0961a1 in (anonymous namespace)::SortableGridDataModel::getRowCount() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#13 0x00007f0aff1dae5c in svt::table::UnoControlTableModel::getRowCount() const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#14 0x00007f0aff1312b5 in svt::table::TableControl_Impl::doPaintContent(OutputDevice&, tools::Rectangle const&) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#15 0x00007f0aff149fc9 in svt::table::TableDataWindow::Paint(OutputDevice&, tools::Rectangle const&) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libtklo.so
#16 0x00007f0afb41f321 in PaintHelper::DoPaint(vcl::Region const*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#17 0x00007f0afb42074f in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#18 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#19 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#20 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#21 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#22 0x00007f0afb41ff57 in PaintHelper::~PaintHelper() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#23 0x00007f0afb4207d6 in vcl::Window::ImplCallPaint(vcl::Region const*, ImplPaintFlags) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#24 0x00007f0afb420c7e in vcl::Window::ImplCallOverlapPaint() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#25 0x00007f0afb420e34 in vcl::Window::ImplHandlePaintHdl(Timer*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#26 0x00007f0afb420cbd in vcl::Window::LinkStubImplHandlePaintHdl(void*, Timer*) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#27 0x00007f0afbe37178 in Link<Timer*, void>::Call(Timer*) const () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#28 0x00007f0afbe36fcc in Timer::Invoke() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#29 0x00007f0afbdd92f9 in Scheduler::CallbackTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#30 0x00007f0afc32ee86 in SalTimer::CallCallback() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#31 0x00007f0afc32ce9e in SvpSalInstance::CheckTimeout(bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#32 0x00007f0afc32e07d in SvpSalInstance::ImplYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#33 0x00007f0afc32e678 in SvpSalInstance::DoYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#34 0x00007f0afbe08bfc in InnerYield(bool, bool) () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#35 0x00007f0afbe083cb in Application::Yield() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#36 0x00007f0afbe08167 in Application::Execute() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#37 0x00007f0b0744e27a in desktop::Desktop::Main() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libsofficeapp.so
#38 0x00007f0afbe33c83 in ImplSVMainRun() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#39 0x00007f0afbd2ff31 in SalInstance::SVMainRun() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#40 0x00007f0afbe33082 in ImplSVMain() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#41 0x00007f0afbe34ee9 in SVMain() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libvcllo.so
#42 0x00007f0b074d143c in soffice_main () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/instdir/program/libsofficeapp.so
#43 0x000055da4f9609bd in sal_main () at desktop/source/app/main.c:51
ret = 8
#44 0x000055da4f960997 in main (argc=8, argv=0x7ffe8beae9c8) at desktop/source/app/main.c:49
ret = 538976288
This looks like event processing might have been triggered that
triggers the (re)paint of the TableDataWindow/TableControl_Impl
(frames #15 and #14), but then dereferencing the UnoControlTableModel's
data model in frame #11 fails, maybe because the data model has already
been disposed earlier?
Dispose the grid control at the end of the testView() Java test that is
the one that creates it and the only one using it, so that happens
before the model and data model etc. get disposed in impl_dispose() that gets
called from cleanupTestCase().
That is to prevent that a repaint is still attempted.
(When the TableControl is disposed, it's model is unset,
so svt::table::TableControl_Impl::doPaintContent (frame #14
in the backtrace) will return early, before trying to call
svt::table::UnoControlTableModel::getRowCount that is seen
in frame #13 of the above backtrace.)
Note: The above backtrace does not yet include the commits
refactoring TableControl and TableControl_Impl like
commit 39749ff5b4
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:30:10 2026 +0200
toolkit: Merge TableControl into TableControl_Impl
and
commit b580576a4d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:44:17 2026 +0200
toolkit: Rename TableControl_Impl to TableControl
and
commit e4f1a48967
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:48:54 2026 +0200
toolkit: Rename TableControl header/source to match new class name
, so the naming and exact code differs slightly with current master,
but as far as I can tell, that otherwise shouldn't have any effect on
the observed behavior.
This is an attempt to address the JunitTest_toolkit_complex failures
mentioned above, without being able to actually verify that locally
(as the failure could not be reproduced locally either).
[1] https://lists.freedesktop.org/archives/libreoffice/2026-September/094885.html
[2] https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/212155/console
Change-Id: If1a5411c92dfdfb49a34b31f4e44ac47d409772c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211231
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Following
Change-Id: I54e578098684a027c9bf2f192a5af3fecb4e65d7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:44:17 2026 +0200
toolkit: Rename TableControl_Impl to TableControl
, also rename the header and source file to match
with the new class name.
(See that commit's commit message for more background.)
Change-Id: I5d7c4251902689718b9b2f3217671cad5b071201
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211163
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As mentioned in previous commit
Change-Id: I82c89866e90f4d29964626d483872e0eafbc4dbe
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 15:30:10 2026 +0200
toolkit: Merge TableControl into TableControl_Impl
, rename TableControl_Impl to simply TableControl,
now that the two classes were merged.
The header and source
file will also be renamed accordingly.
Do it as a separate step to keep the diff of the
single commits clearer.
Change-Id: I54e578098684a027c9bf2f192a5af3fecb4e65d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211162
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, most of the logic for the TableControl
widget was implemented in the TableControl_Impl
implementation class that was held by the
TableControl via a std::shared_ptr
(TableControl::m_pImpl member).
However, other classes were also using the
TableControl_Impl directly.
Stop that separation and simplify code by merging
TableControl into TableControl_Impl. As mentioned,
the latter already implemented most of the logic,
so it is easier to merge the remaining logic into
that class than the other way around.
Move the remaining TableControl logic into
TableControl_Impl, in particular make TableControl_Impl
a Control subclass and move the vcl::Window/Control
overrides to TableControl_Impl.
Now that TableControl_Impl is a vcl::Window subclass,
VclPtr is the appropriate way for handling shared
ownership and no longer std::shared_ptr.
Therefore, switch to using VclPtr instead of shared_ptr
in the corresponding ITableModel methods
(ITableModel::addTableModelListener and
ITableModel::removeTableModelListener) and corresponding
data structures used in the subclasses.
See also commit message of previous commit
Change-Id: I74b9b29f03d03571709d1c8a7b416b0a6a12319a
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Fri Sep 18 11:07:29 2026 +0200
toolkit: Use TableControl_Impl directly instead of ITableModelListener
that was already preparing for that change.
No change in behavior intended.
Now that there is no more TableControl that owns it,
it makes sense to rename TableControl_Impl to TableControl.
That will happen in a separate upcoming commit, to keep
the diff clearer/more manageable.
Change-Id: I82c89866e90f4d29964626d483872e0eafbc4dbe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211161
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from pointer to reference, which makes clear that
it's always non-null. Rename accordingly.
Change-Id: If8a3597d1fb42f7714bbdafd1dde2826d6f46824
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211160
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the enum class to its own header, to avoid having
to include the header definining the TableControl class
in order to use AccessibleTableControlObjType.
This is in preparation of merging the TableControl
class into the TableControl_Impl one.
Change-Id: Idc4e970e9d63352df3a177cda716acb65cbd76ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211159
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In most of its methods, TableControl simply calls a corresponding
method in TableControl_Impl. Most of them have the same name
in both classes, but start with an upper case letter in TableControl
and a lower case letter in TableControl_Impl.
Align the names to match, mostly by switching the TableControl_Impl
variants to also start with an upper case letter, and renaming a few
others that had different names.
This is in preparation of merging TableControl into TableControl_Impl,
so that the callers of the methods don't need to be adjusted to
use the (so far) differing method names.
Change-Id: Ie554a6f889f8993b37e494d2e66f3e4d88d503eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211158
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Those are partially used in TableControl_Impl and elsewhere.
On the other hand, TableControl uses sal_Int32 directly,
i.e. the TableControl methods using sal_Int32 call the
TableControl_Impl equivalents using the typedefs.
Unify this to consistently use sal_Int32 directly.
This will also make merging TableControl and
TableControl_Impl more straightforward, which
is planned for an upcoming commit.
Change-Id: I96c83bcd69ad84012194865f19ad0fc507f11e1e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211157
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
TableControl_Impl is the only class implementing/subclassing the
ITableModelListener interface/base class.
Switch to using TableControl_Impl directly instead of the
abstract base class. This also requires that TableControl_Impl
now needs to subclass std::enable_shared_from_this instead
of ITableModelListener doing so.
This commmit prepares for merging TableControl and TableControl_Impl
in an upcoming commit, at which point the std::shared_ptr will
be replaced by a VclPtr as TableControl is a vcl::Window subclass.
Change-Id: I74b9b29f03d03571709d1c8a7b416b0a6a12319a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211156
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: I19e2c30d9b6c09a1621fd9097ab394e80c9821b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211155
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: I9540a25c008d003b24c52309255b9009e01d09eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211154
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
This commit is part of a series to implement that approach
for more methods by moving the logic to TableControl_Impl,
to make the handling more consistent and prepare for merging
TableControl and TableControl_Impl in an upcoming commit.
Change-Id: Ibf26eebf0506d6cfc5448064075eae9412ff1fc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211153
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
Implement that approach for more methods by moving the
logic to TableControl_Impl, to make the handling more
consistent and prepare for merging TableControl and
TableControl_Impl in an upcoming commit.
Change-Id: Ic551ed5e3a0298744602dd0c0abbaa9e1662fc9f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211152
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It does the same as TableControl::GoToCell, so replace the
only call to the former with a call to the latter.
Change-Id: I85905afb0e56a4b00686723a7e80a12f1519bdd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211151
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Most of the TableControl logic is already implemented
in its implementation class, TableControl_Impl and
most TableControl methods just forward to the
corresponding TableControl_Impl ones.
Implement that approach for more methods by moving the
logic to TableControl_Impl, to make the handling more
consistent and prepare for merging TableControl and
TableControl_Impl in an upcoming commit.
Change-Id: If2b911371aad21a28f396d473f9e0dd7e5b33fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211094
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
SVTXGridControl::m_xTableModel is a
std::shared_ptr<svt::table::UnoControlTableModel> and
svt::table::UnoControlTableModel is a ITableModel subclass,
so can be passed as is, without the need to explicitly
construct a std::shared_ptr<ITableModel>.
Change-Id: Ifecbc38634ff747d3b28077338114d6437e6ebc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211093
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the TableFunctionSet class definition and implementation out of the
header/source used for TableControl_Impl to an own/separate one.
This is in preparation of merging TableControl_Impl with
TableControl in an upcoming commit.
Change-Id: I9a0f9cd37db5763e8cd9deea727f2fe036b9375f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211091
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It's only subclassed/implemented by TableControl_Impl
and that one is used directly everywhere now.
Drop ITableControl altogether.
Take over comments/documentation for its (previously
virtual) methods to the corresponding TableControl_Impl methods
and no longer mark those as virtual.
Change-Id: I2d02bd7de8d6b037765e4c04a8f65ad509ffdf05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211085
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch members/params from the abstract ITableControl to the
concrete TableControl_Impl that is the only actual implementation/
subclass of ITableControl.
This is in preparation of Dropping ITableControl completely in
an upcoming commit.
Change-Id: I1b3bcb87f771f64dd7bf07f1047279524de432fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211084
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Make the header a bit more widely available inside the
toolkit module.
This is in preparation of merging TableControl_Impl with
its abstract ITableControl base class/interface and
merging TableControl with TableControl_Impl in upcoming
commits.
Change-Id: Id38183ac369f9d90571904816b1f3fbce1e12fa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211083
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This in particular also gets rid of an extra level of indentation
in toolkit/source/controls/table/mousefunction.cxx.
Change-Id: I1e5f8db7b281fb1d68d7819c5d99efae13c0cea4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211081
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
TableControl_Impl subclasses ITableModelListener
which in turn subclasses
std::enable_shared_from_this<ITableModelListener>
and TableControl_Impl uses
std::enable_shared_from_this<ITableModelListener>::shared_from_this
(in TableControl_Impl::setModel) to generate additional
shared_ptr instances sharing the ownership.
(See also std::enable_shared_from_this doc at [1].)
Therefore, it needs to be held by std::shared_ptr itself.
Document that, as it wasn't initially obvious to me.
(A failed attempt to switch to std::unique_ptr caused
JunitTest_toolkit_complex to fail and reveal the issue.)
[1] https://en.cppreference.com/cpp/memory/enable_shared_from_this
Change-Id: Idf446067d7d4f86809e34872d2d41ff7f4ac7424
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211079
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from the abstract XAccessible UNO interface to the
more concrete OAccessible for AccessibleGridControlBase::m_xParent
and rename accordingly.
Drop now no longer needed method calls and UNO queries
to get the XAccessibleContext and XAccessibleComponent interfaces,
because OAccessible directly implements those interfaces
itself as well.
Change-Id: I39e8453f087568c78c2f7de6634d87bde2717956
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210633
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: I4880448db03dcc89076dc72d45902c0bf2f16d83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210632
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: Id2c3cb8c9095f338c5c1072bf86486bbf9260a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210631
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Pass a more concrete OAccessible instead of the abstract
XAccessible UNO interface for the parent param.
Change-Id: I0a363d3174b304f019f7005cc5d7f219d0e150b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210630
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch the local variable from the abstract XAccessible UNO
interface to the more concrete OAccessible base class.
This also prepares for more upcoming changes.
Change-Id: I8f33c4bea80052ebfc0d2ec21889f865e0cc5d6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210627
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass.
Pass that more concrete type for the parent param instead
of the abstract XAccessible UNO interface.
Change-Id: If072062b295195b9599ad20af72d4fbf3eb6fc8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210626
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent of a AccessibleGridControlTableCell is always the
AccessibleGridControlTable it belongs to.
Pass that concrete type to the ctor instead of the abstract
XAccessible UNO interface.
Change-Id: I3ff1c0f9f1a9bd81d07b8ff825b11d763c3863cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210625
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent of a AccessibleGridControlHeaderCell is always the
AccessibleGridControlHeader it belongs to.
Pass that concrete type to the ctor instead of the abstract
XAccessible UNO interface.
Change-Id: I17069674b5bd853e07b6b1551f291994f21c7eb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210624
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the ctor
instead of the abstract XAccessible UNO interface.
Change-Id: I938d73cef38385a562b516758bdbb7bb8d7dc5bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210623
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the ctor
instead of the abstract XAccessible UNO interface.
Change-Id: Icaeca70a28b87c2b2f9e5b07581777f0dd4cec3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210622
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The parent is always an OAccessible subclass, so use that
more concrete type for the parent param of the
AccessibleGridControlHeader ctor instead of the
abstract XAccessible UNO interface.
Change-Id: Ib0575f725f553b8345bd3f02085fa073a500cd92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210621
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
By now, almost all a11y implementations implement both,
the XAccessible and XAccessibleContext interfaces themselves,
and they do so via the OAccessible base class.
One remaining case that only implements the XAccessible interface
directly is UnoControl. XAccessible::getAccessibleContext
is used from within AccessibleControlShape::Init to get the
accessible context. That accessible context however
is an OAccessible and implements both, the XAccessible
and XAccessibleContext interfaces again.
Stop requiring that UnoControl implements XAccessible
by instead adding a dedicated new method UnoControl::getAccessible
to directly get the OAccessible without relying on
the XAccessible interface being implemented by UnoControl.
In AccessibleControlShape::Init, cast to UnoControl
instead of querying for the XAccessible interface
and call the new method directly.
Stop implementing the XAccessible interface in
UnoControl as it is no longer needed now.
This aligns the UnoControl a11y logic more with how
a11y is implemented elsewhere across the code base.
Sample steps to trigger the modified code
when using the gtk3 vcl plugin on Linux:
* start the Orca screen reader
* start Writer
* insert a few push button controls using
"Form" -> "Push Button" and then clicking into
the document and dragging to insert
* disable design mode using "Form" -> "Design Mode"
* focus one of the controls by clicking on it
* press the Tab key to move focus between the controls
No differences in behavior were observed when
doing this with or without this change in place.
Side note: Announcement of the controls when they
receive focus didn't work (reliably) when opening an
existing document containing form controls instead of
inserting them into a new one, but that is preexisting
and unrelated to this commit.
Also adjust test AccessibleFixedTextTest::testFixedText
of the CppunitTest_toolkit_a11y test suite
accordingly that was assuming that it can
query the XAccessible interface directly
from the UNO control.
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the more concrete OAccessible instead of a reference
to the abstract XComponent UNO interface.
Change-Id: Idcbf5c1eb09cc1380a85410b76d8b1e2df022b6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from using a weak reference (css::uno::WeakReferenceHelper)
to the abstract XAccessibleContext UNO interface to a weak
reference (unotools::WeakReference) of the more concrete
OAccessible class in UnoControl.
This makes clear that the accessible is always an OAccessible
subclass and allows dropping some UNO-querying for the
wanted UNO interfaces.
Change-Id: Ib1ea66c83da9bbf76891c492d84aa57c396f2f44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The UNO service specific to the status bar was
dropped in
Change-Id: I0d1cb8353fac37a3db9833a06fa439cc94e6c9b3
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 1 16:01:28 2026 +0200
[API CHANGE] a11y: Drop com.sun.star.awt.AccessibleStatusBar
and more UNO service descriptions will be dropped as they
are an implementation detail and not relevant to implement a11y
support.
Don't rely on XServiceInfo being implemented in
the AccessibleStatusBarTest, to prepare for the upcoming
removal of those services.
Change-Id: Ib545820a52bcb4d4f99239e438840b1562831c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210405
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleGridControlBase (and drop related
XServiceInfo::getImplementationName overrides in subclasses),
in preparation of dropping the service altogether in an upcoming
commit.
Change-Id: I66e6390ad77e3ff0febfb335c312954815c6581c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210400
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -21,7 +21,7 @@
#i86008 -o toolkit.AccessibleComboBox
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
-#i86110 -o toolkit.AccessibleList
+-o toolkit.AccessibleList
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
This commit is similar to the previous
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 1 16:28:30 2026 +0200
a11y tests: Drop obsolete, long disabled AccessibleListBox Java test
, but now for the AccessibleList test.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: I1e0469f8f265d564cdcaf81aa1bdc8e718e49a26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210349
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -22,7 +22,7 @@
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
#i86110 -o toolkit.AccessibleList
-#i86110 -o toolkit.AccessibleListBox
+-o toolkit.AccessibleListBox
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210348
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Michael Weghorn