/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ /* * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ #pragma once namespace writerperfect { /** Definition of XML import service used with a Generator. This template must be specialized for every libodfgen generator. */ template struct DocumentHandlerFor { // static OUString name(); }; } /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ gmann@allotropia.de> Tested-by: Jenkins 
Change-Id: I574ae3404ce4a9ad75176f2e2066563da60136ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175809
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
gtk3 a11y tests: Always use dbus-daemon for the AT-SPI bus 2024-08-01T08:18:19+00:00 Michael Weghorn m.weghorn@posteo.de 2024-08-01T06:38:05+00:00 ca74f594d698b0b7dd138f90d6eaa7edd4a22cf7 at-spi-bus-launcher launches a separate DBus instance for AT-SPI, and prefers dbus-broker over dbus-daemon when the corresponding build option was set and dbus-broker is present. However, trying to launch a bus using dbus-broker fails in the environment created for the gtk3 a11y tests, which are run using `xvfb-run` and use a separate session bus created using `dbus-launch`, (i.e. the dbus-daemon implementation). See [1] (and other messages of that email thread) and [2] for more details. Avoid the problem of mixing different DBus implementations by setting an environment variable that makes at-spi-bus-launcher use dbus-daemon instead of dbus-broker regardless of how it was configured at build time. This depends on at-spi2-core commit [3] for at-spi-bus-launcher to actually evaluate the environment variable: commit e735ed9135517532d37f7dab546786f8b4d39283 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Wed Jul 31 11:27:27 2024 +0200 at-spi-bus-launcher: Introduce env var to select DBus implementation In at-spi-bus-launcher, introduce evaluation of an environment variable `ATSPI_DBUS_IMPLEMENTATION` to allow explicitly overriding the DBus implementation to use. In case of `ATSPI_DBUS_IMPLEMENTATION=dbus-daemon`, don't try to use dbus-broker, and vice versa. This can e.g. be useful for tests in environments where dbus-broker is installed and was configured as the preferred DBus implementation at at-spi2-core build time, but cannot be run in the test environment, e.g. when tests are run via xvfb-run --auto-servernum dbus-run-session [...] Thanks to Colomban Wendling for mentioning that idea in [1]. [1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/49#note_1854645 Related: #49 This makes make CppunitTest_vcl_gtk3_a11y pass on a current Fedora Rawhide when using a self-built at-spi2-core from its git main branch. [1] https://lists.freedesktop.org/archives/libreoffice/2023-August/090853.html [2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/49 [3] https://gitlab.gnome.org/GNOME/at-spi2-core/-/commit/e735ed9135517532d37f7dab546786f8b4d39283 Change-Id: Ifd84ef1f993398423ac0e0f695c1c0323adf02b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171366 Reviewed-by: Colomban Wendling <cwendling@hypra.fr> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins 
at-spi-bus-launcher launches a separate DBus instance for
AT-SPI, and prefers dbus-broker over dbus-daemon when the
corresponding build option was set and dbus-broker is present.

However, trying to launch a bus using dbus-broker fails
in the environment created for the gtk3 a11y tests, which
are run using `xvfb-run` and use a separate session bus
created using `dbus-launch`, (i.e. the dbus-daemon
implementation).

See [1] (and other messages of that email thread) and [2]
for more details.

Avoid the problem of mixing different DBus implementations
by setting an environment variable that makes at-spi-bus-launcher
use dbus-daemon instead of dbus-broker regardless of how
it was configured at build time.

This depends on at-spi2-core commit [3] for at-spi-bus-launcher
to actually evaluate the environment variable:

    commit e735ed9135517532d37f7dab546786f8b4d39283
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Wed Jul 31 11:27:27 2024 +0200

        at-spi-bus-launcher: Introduce env var to select DBus implementation

        In at-spi-bus-launcher, introduce evaluation
        of an environment variable `ATSPI_DBUS_IMPLEMENTATION`
        to allow explicitly overriding the DBus implementation
        to use.

        In case of `ATSPI_DBUS_IMPLEMENTATION=dbus-daemon`, don't try
        to use dbus-broker, and vice versa.

        This can e.g. be useful for tests in environments where
        dbus-broker is installed and was configured as the
        preferred DBus implementation at at-spi2-core build time,
        but cannot be run in the test environment, e.g. when
        tests are run via

            xvfb-run --auto-servernum dbus-run-session [...]

        Thanks to Colomban Wendling for mentioning that idea
        in [1].

        [1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/49#note_1854645

        Related: #49

This makes

    make CppunitTest_vcl_gtk3_a11y

pass on a current Fedora Rawhide when using a self-built at-spi2-core
from its git main branch.

[1] https://lists.freedesktop.org/archives/libreoffice/2023-August/090853.html
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/49
[3] https://gitlab.gnome.org/GNOME/at-spi2-core/-/commit/e735ed9135517532d37f7dab546786f8b4d39283

Change-Id: Ifd84ef1f993398423ac0e0f695c1c0323adf02b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171366
Reviewed-by: Colomban Wendling <cwendling@hypra.fr>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
gtk3 a11y test: Let xvfb-run auto-determine free server num 2023-10-17T05:50:37+00:00 Michael Weghorn m.weghorn@posteo.de 2023-10-16T09:03:46+00:00 ca01deadcbc480b6e79618b227a2b73a61ecb7ff As the xvfb-run manpage says, it uses a default server number of 99: > -n servernumber, --server-num=servernumber > Use servernumber as the server number (but see the -a, --auto-servernum option above). The default is 99. The gtk3 a11y tests use xvfb-run. Running the test multiple times in parallel (e.g. when doing two separate builds with tests, as happens on CI) would fall like this on Debian testing: $ make CppunitTest_vcl_gtk3_a11y make -j 12 -rs -f /home/michi/development/git/libreoffice/Makefile.gbuild CppunitTest_vcl_gtk3_a11y [CUT] vcl_gtk3_a11y xvfb-run: error: Xvfb failed to start Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. No coredumps found. Error: a unit test failed, please do one of: make CppunitTest_vcl_gtk3_a11y CPPUNITTRACE="gdb --args" # for interactive debugging on Linux make CppunitTest_vcl_gtk3_a11y VALGRIND=memcheck # for memory checking make CppunitTest_vcl_gtk3_a11y DEBUGCPPUNIT=TRUE # for exception catching You can limit the execution to just one particular test by: make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params... However, it behaves differently on Alma Linux 8, where it looks like xvfb-run seems then to reuse the existing Xfvb session, causing the tests to potentially find the LibreOffice instance from another test run, and then inspecting the wrong one, leading to failures like the one in [1]: equality assertion failed - Expected: ecclectic.fodt — LibreOfficeDev Writer - Actual : ecclectic.fodt — LibreOfficeDev Writer 24.2 [9bc2aede99017ed0338e97b21b4735919b705b47] The fact that the second instance of xvfb-run reuses the session of the firs one and finds the LibreOffice there can also be reproduced on Alma Linux 8 by just running these 2 commands in parallel: 1) start LO in xfvb-run session: $ xvfb-run dbus-launch libreoffice 2) run below Python script that lists the running applications: $ xvfb-run dbus-launch python3 /home/vagrant/atspi-list-apps.py --------start-------- [application | soffice] --------end-------- /usr/bin/xvfb-run: line 186: kill: (27078) - No such process This *should not* list the applications from the other xfvb-run. It works as expected when passing `--auto-servernum`: $ xvfb-run --auto-servernum dbus-launch python3 /home/vagrant/atspi-list-apps.py --------start-------- --------end-------- Therefore, pass the `--auto-servernum` arg to xvfb-run, so that it automatically determines a free server number instead. > -a, --auto-servernum > Try to get a free server number, starting at 99, or the argument to --server-num. Python script mentioned above used for testing: $ cat atspi-list-apps.py #!/usr/bin/python3 import pyatspi registry = pyatspi.registry.Registry() apps = list(registry.getDesktop(0)) print('--------start--------') for app in apps: print(f'{app}') print('--------end--------') [1] https://ci.libreoffice.org/job/gerrit_linux_gcc_release/151750/consoleFull#-1985341263d893063f-7f3d-4b7e-b56f-4e0f225817cd Change-Id: I0673212fb8fed5c9698c9f797b7bf49ba51033b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158021 Tested-by: Jenkins Reviewed-by: Colomban Wendling <cwendling@hypra.fr> Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> 
As the xvfb-run manpage says, it uses a default server number of 99:

>      -n servernumber, --server-num=servernumber
>             Use servernumber as the server number (but see the -a, --auto-servernum option above).  The default is 99.

The gtk3 a11y tests use xvfb-run. Running the test multiple
times in parallel (e.g. when doing two separate builds with
tests, as happens on CI) would fall like this on Debian testing:

    $ make CppunitTest_vcl_gtk3_a11y
    make -j 12 -rs -f /home/michi/development/git/libreoffice/Makefile.gbuild CppunitTest_vcl_gtk3_a11y
    [CUT] vcl_gtk3_a11y
    xvfb-run: error: Xvfb failed to start
    Hint: You are currently not seeing messages from other users and the system.
          Users in groups 'adm', 'systemd-journal' can see all messages.
          Pass -q to turn off this notice.
    No coredumps found.

    Error: a unit test failed, please do one of:

    make CppunitTest_vcl_gtk3_a11y CPPUNITTRACE="gdb --args"
        # for interactive debugging on Linux
    make CppunitTest_vcl_gtk3_a11y VALGRIND=memcheck
        # for memory checking
    make CppunitTest_vcl_gtk3_a11y DEBUGCPPUNIT=TRUE
        # for exception catching

    You can limit the execution to just one particular test by:

    make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...

However, it behaves differently on Alma Linux 8, where it
looks like xvfb-run seems then to reuse the existing
Xfvb session, causing the tests to potentially find
the LibreOffice instance from another test run, and
then inspecting the wrong one, leading to failures
like the one in [1]:

    equality assertion failed
    - Expected: ecclectic.fodt — LibreOfficeDev Writer
    - Actual  : ecclectic.fodt — LibreOfficeDev Writer 24.2 [9bc2aede99017ed0338e97b21b4735919b705b47]

The fact that the second instance of xvfb-run
reuses the session of the firs one and finds the
LibreOffice there can also be reproduced on Alma Linux 8
by just running these 2 commands in parallel:

1) start LO in xfvb-run session:

    $ xvfb-run dbus-launch libreoffice

2) run below Python script that lists the
   running applications:

    $ xvfb-run dbus-launch python3 /home/vagrant/atspi-list-apps.py
    --------start--------
    [application | soffice]
    --------end--------
    /usr/bin/xvfb-run: line 186: kill: (27078) - No such process

This *should not* list the applications from
the other xfvb-run.

It works as expected when passing `--auto-servernum`:

    $ xvfb-run --auto-servernum dbus-launch python3 /home/vagrant/atspi-list-apps.py
    --------start--------
    --------end--------

Therefore, pass the `--auto-servernum` arg to xvfb-run, so that it
automatically determines a free server number instead.

>      -a, --auto-servernum
>             Try to get a free server number, starting at 99, or the argument to --server-num.

Python script mentioned above used for testing:

    $ cat atspi-list-apps.py
    #!/usr/bin/python3

    import pyatspi

    registry = pyatspi.registry.Registry()
    apps = list(registry.getDesktop(0))

    print('--------start--------')

    for app in apps:
        print(f'{app}')

    print('--------end--------')

[1] https://ci.libreoffice.org/job/gerrit_linux_gcc_release/151750/consoleFull#-1985341263d893063f-7f3d-4b7e-b56f-4e0f225817cd

Change-Id: I0673212fb8fed5c9698c9f797b7bf49ba51033b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158021
Tested-by: Jenkins
Reviewed-by: Colomban Wendling <cwendling@hypra.fr>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
gtk3 a11y: Force running a11y tests with X11 GDK backend 2023-08-26T12:55:07+00:00 Michael Weghorn m.weghorn@posteo.de 2023-08-25T06:52:19+00:00 3ebd1371cbcfc03ca525146c680f076066ceb361 On Debian testing, tunning the gtk3 a11y tests with make CppunitTest_vcl_gtk3_a11y in a Wayland session resulted in a visible Writer window popping up (while that should not be the case and isn't when run in an X11 session instead, as the application is meant to run in a virtual X server environment via xvfb-run) and a test failed like this: .../vcl/qa/cppunit/a11y/atspi2/atspi2.cxx:432:Test1::TestBody equality assertion failed - Expected: ATSPI_ROLE_PANEL - Actual : ATSPI_ROLE_FILLER warn:sw.core:15950:15950:sw/source/core/attr/calbck.cxx:196: a 16SwTextFormatColl client added as listener to a 16SwTextFormatColl during client iteration. warn:sw.core:15950:15950:sw/source/core/attr/calbck.cxx:196: a 16SwLineNumberInfo client added as listener to a 12SwCharFormat during client iteration. Test1::TestBody finished in: 56011ms atspi2.cxx:432:Assertion Test name: Test1::TestBody equality assertion failed - Expected: ATSPI_ROLE_PANEL - Actual : ATSPI_ROLE_FILLER Failures !!! Run: 1 Failure total: 1 Failures: 1 Errors: 0 Force use of the X11 GDK backend by setting env var `GDK_BACKEND=x11`, which makes that scenario work as expected. Change-Id: I7de03593998ffa3bc18d487cb92e00ae75427598 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156086 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> 
On Debian testing, tunning the gtk3 a11y tests with

    make CppunitTest_vcl_gtk3_a11y

in a Wayland session resulted in a visible
Writer window popping up (while that should not be
the case and isn't when run in an X11 session instead,
as the application is meant to run in a virtual
X server environment via xvfb-run)
and a test failed like this:

    .../vcl/qa/cppunit/a11y/atspi2/atspi2.cxx:432:Test1::TestBody
    equality assertion failed
    - Expected: ATSPI_ROLE_PANEL
    - Actual  : ATSPI_ROLE_FILLER

    warn:sw.core:15950:15950:sw/source/core/attr/calbck.cxx:196: a 16SwTextFormatColl client added as listener to a 16SwTextFormatColl during client iteration.
    warn:sw.core:15950:15950:sw/source/core/attr/calbck.cxx:196: a 16SwLineNumberInfo client added as listener to a 12SwCharFormat during client iteration.
    Test1::TestBody finished in: 56011ms
    atspi2.cxx:432:Assertion
    Test name: Test1::TestBody
    equality assertion failed
    - Expected: ATSPI_ROLE_PANEL
    - Actual  : ATSPI_ROLE_FILLER

    Failures !!!
    Run: 1   Failure total: 1   Failures: 1   Errors: 0

Force use of the X11 GDK backend by setting env
var `GDK_BACKEND=x11`, which makes that scenario
work as expected.

Change-Id: I7de03593998ffa3bc18d487cb92e00ae75427598
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156086
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
vcl gtk3: Introduce AT-SPI2 tests for the GTK3 accessibility layer 2023-07-27T18:01:17+00:00 Colomban Wendling cwendling@hypra.fr 2023-04-05T13:39:25+00:00 3426dcfec2b4d5c755024c355f323ecc9f656e4a Add tests for the GTK3 accessibility platform layer. These tests compare the internal LO representation with what is visible to the platform, and thus the user's accessibility tools. In most cases the tests are fairly trivial as LO's internals are not far off AT-SPI2's expectations. There are however notable exceptions like for example the text attributes, that have a wildly different representation and require more complex checks matching what LO's platform layer does, the other way around. These tests use libatspi2 directly, but as the C API is awful to work with regarding resource management, there are wrappers to handle the complexity using RAII. The resulting API is fairly trivial to use. As these tests require using the GTK3 VCL plugin and for the a11y tree to be visible to AT-SPI2, they are run under XVFB using a separate dbus session through dbus-launch. Working on this has already lead to reporting and/or solving some issues: * https://gerrit.libreoffice.org/c/core/+/151303 * https://gerrit.libreoffice.org/c/core/+/151650 * https://gerrit.libreoffice.org/c/core/+/152456 * https://gerrit.libreoffice.org/c/core/+/152457 * https://bugs.documentfoundation.org/show_bug.cgi?id=155625 * https://bugs.documentfoundation.org/show_bug.cgi?id=155705 * https://gerrit.libreoffice.org/c/core/+/152748 Only a subset of the a11y APIs are covered for the moment, but the current state should make it easy to extend upon. Change-Id: I1a047864ce8dc1f1bc3056ad00159f7fd5e5b7d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153069 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> 
Add tests for the GTK3 accessibility platform layer.  These tests
compare the internal LO representation with what is visible to the
platform, and thus the user's accessibility tools.

In most cases the tests are fairly trivial as LO's internals are not
far off AT-SPI2's expectations.  There are however notable exceptions
like for example the text attributes, that have a wildly different
representation and require more complex checks matching what LO's
platform layer does, the other way around.

These tests use libatspi2 directly, but as the C API is awful to work
with regarding resource management, there are wrappers to handle the
complexity using RAII.  The resulting API is fairly trivial to use.

As these tests require using the GTK3 VCL plugin and for the a11y tree
to be visible to AT-SPI2, they are run under XVFB using a separate dbus
session through dbus-launch.

Working on this has already lead to reporting and/or solving some
issues:

* https://gerrit.libreoffice.org/c/core/+/151303
* https://gerrit.libreoffice.org/c/core/+/151650
* https://gerrit.libreoffice.org/c/core/+/152456
* https://gerrit.libreoffice.org/c/core/+/152457
* https://bugs.documentfoundation.org/show_bug.cgi?id=155625
* https://bugs.documentfoundation.org/show_bug.cgi?id=155705
* https://gerrit.libreoffice.org/c/core/+/152748

Only a subset of the a11y APIs are covered for the moment, but the
current state should make it easy to extend upon.

Change-Id: I1a047864ce8dc1f1bc3056ad00159f7fd5e5b7d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153069
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>