These tests can be run manually, but are not suitable for use as an
acceptance test, so let's not make frameworks like Debian's autopkgtest
run these when they run ginsttest-runner in the most obvious way.
a11ytests.test doesn't seem to be reliable enough to be used as a QA
acceptance criterion, and has been disabled as a build-time test in both
Gitlab-CI and Debian since 2019. a11ystate.test is not set up to be run
at build time at all, and has been marked as flaky on ci.debian.net
since 2018.
The rest of the testsuite/a11y directory seems to have been
reliable in practice, at least on ci.debian.net, so try leaving them
enabled as installed-tests.
In principle this could be made finer-grained by having a separate .test
file and a separate Meson test() for each .ui file, but that would
require more active maintenance of GTK 3.
Signed-off-by: Simon McVittie <smcv@debian.org>
At least some of the tests implemented via the accessibility-dump
executable are known to be unstable, but the tests based on separate
executables (tree-performance.c, etc.) have been reasonably consistently
passing on ci.debian.net for several years, so hopefully they are also
reliable enough for upstream CI and we don't need to mark them as flaky?
Signed-off-by: Simon McVittie <smcv@debian.org>
There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.
In GTK 3.24.35, if the environment is such that the label-sizing.ui
reftest happens to be successful, the overall result of the test suite
is failure. This seems unlikely to have been the intention.
Instead of using should_fail, put the tests in one of two new suites:
"flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
with a command like:
meson test --setup=unstable_tests --suite=flaky --suite=failing
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Signed-off-by: Simon McVittie <smcv@debian.org>
The merge request !5235 switched tests and examples from
G_APPLICATION_FLAGS_NONE, which has been deprecated in GLib 2.74, to
G_APPLICATION_DEFAULT_FLAGS. Sadly, it was done unconditionally, which
means we'd have to bump the required version of GLib.
To avoid that, let's just use the numeric value of the enum member.
This fixes Autotools builds that disable Wayland, such as non-Linux
operating systems and the minimal "udeb" (micro-.deb) package used in
Debian's installer.
Signed-off-by: Simon McVittie <smcv@debian.org>
mouse_location can be set to NULL in gtk_range_update_mouse_location(). This
causes a match with stepper_?_gadget in gtk_range_multipress_gesture_pressed(),
as both are NULL. This leads to a grab being added internally and as well, a
critical error message, and a subsequent rejection of touch inputs. Returning
early when mouse_location is NULL prevents this.
Closes#4947
