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
GtkSettings/X11 takes the values as provided by
XSettings. Unlike other backends, the values of
XSettings are in physical size (that's because
X11 doesn't support mixed-DPI setups anyway).
Take that in account when retrieving the cursor
size in gtk_tooltip_position ().
Note that this discrepancy between the X11 and
other backends has been fixed in GTK4.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5223
This way we can keep the same wayland-protocols requirement, so the latest GTK3
still builds on distributions shipping older versions of wayland-protocols,
such as Debian Bullseye.
Should fix CI builds as well.
Use a separate queue to dispatch the token object exclusively, just like we
do on the GdkSurface activation paths.
Backport-of: fb68600d88d4d334f7da7d079b106a1ef14503a6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Currently, we have all the plumbing in place so that GTK consumes the
startup notification ID when focusing a window through the xdg-activation
protocol.
This however misses the case that a window might be requested to be
focused with no startup ID (i.e. via interaction with the application,
not through GApplication or other application launching logic).
In this case, we let the application create a token that will be
consumed by itself. The serial used is that from the last
interaction, so the compositor will still be able to do focus prevention
logic if it applies.
Since we already do have a last serial at hand, prefer xdg-activation
all the way over the now stale gtk-shell focusing support. The timestamp
argument becomes unused, but that is a weak argument to prefer the
private protocol over the standard one. The gtk-shell protocol support
is so far left for interaction with older Mutter.
Backport-of: 4dcacff3120d5c1cef888061dbc42f5fbe093a58
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
When using xdg_activation we need to keep the id around until we send
the first activate to signal succesful startup.
Backport-of: 999509be619bfa0f50a549489b5ab5c890b574fa
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Tools like gtk4-launch can't set surface on the activation token so
don't require it. If the compositor requires it we can't do anything
about it anyway. This avoids a critical:
(gtk4-launch:23497): Gdk-CRITICAL **: 17:07:24.704: gdk_wayland_surface_get_wl_surface: assertion 'GDK_IS_WAYLAND_SURFACE (surface)' failed
Fixes: be4216e051 ("gdk/wayland: Support the xdg-activation wayland protocol")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Backport-of: 4d741bac98f906796d61eebfb4f74f5b1cecb2b6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
