This was the type the function expected, but we were actually passing
the global context to it.
This didn't crash for some reason, but indeed it was wrong and we didn't
catch it because mutter side had not type-checks either
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3355>
(cherry picked from commit 9abad7f25f)
If no child setup is provided then all the shell extensions that use
GLib.spawn_async should actually use the shell spawning utils since we
are supposed to always restore the default nofile rlimit on launched
children.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 64edd7940d)
Using child setup functions is unsafe in gjs code so let's warn if this
happens so that extensions using a similar codepath are warned.
This could be also part of gjs, but we provide a shell override since we
have alternatives to log about.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 494be30764)
In the shell code we often use GLib.spawn_async to launch processes
with a GSpawnChildSetupFunc implementation in JavaScript to reset the
mutter nofile rlimit in the new child process.
However, this is highly unsafe to do because this implies that the child
setup function code is executed in gjs where a lot of allocations are
done and even more not-async-signal-safe code is executed, in fact
leading to dead-locks as reported in the past.
To prevent this, declare a new functions that do the same of the GLib
counterpart but without providing a GSpawnChildSetupFunc that is instead
implemented in the C-side doing the cleanup that mutter requires without
allocations or async-signal-unsafe code.
Helps: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6698
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit 781010be66)
The child context setup function used as launch GSpawnChildSetupFunc
uses g_object_get that internally potentially allocates memory, making
it not async-signal-safe and so not something that is safe to use in
between fork and exec, so just use the simpler getter here.
Note that the current implementation of app_child_setup() is safe
already as sd_journal_stream_fd, dup2 and close are so.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3293>
(cherry picked from commit dcb5956dea)
In the future, the module will automate uploading the release
tarball. We already use the CI pipeline to generate the tarball,
so it's easy to hook up the module and provide some testing
before the module goes into production.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
(cherry picked from commit 1fbfb93cbd)
We currently assume that the `CI_COMMIT_TAG` variable matches the
version component of the generated dist tarball.
That is usually correct, but sometimes errors happen and a wrong
tag is pushed, and the real release uses something like "46.0-real".
Account for that by building the artifact path from `meson introspect`
and exporting it as environment variable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3340>
(cherry picked from commit 27445a1c98)
The offset in high contrast mode was moving the dot too close to the
text making the spacing between the text, dot and hover highlight appear
visually unbalanced. Also it was making it more likely to overlap
descenders in the text.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit 559d38c259)
With the dot now being placed correctly at the bottom of the hover
highlight it is now also overlapping the 1px inset shadow used as
outline in high contrast mode. To avoid this, shift the dot up
accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit e2adc5a445)
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
(cherry picked from commit 31997fa2f9)
We currently compute the target scale from the allocated height,
which means that it only becomes available after thumbnails have
been allocated at least once at their expanded height.
As the minimap is initially hidden, this only happens after it is
expanded for the first time, which means the corresponding transition
is not animated.
In order to allow for a fix, compute the target height ourselves
to allow the scale computation to work independently from the
expand factor.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3331>
(cherry picked from commit 2694a64ebb)
The auth prompt currently propagates all key presses, even the
Escape press that is used to cancel it.
On the lock screen that means that the same event that cancels
the prompt (and switches back to the clock) is *also* propagated
to the handler that activates the prompt on key press.
That handler doesn't do anything when the prompt is already visible,
which is the case when the transition to the clock is animated.
However when animations are disabled, canceling the prompt will
result in a new prompt getting created immediately, and the login
screen is stuck on the prompt.
Fix this by not propagating key events that are used to cancel
the prompt.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
(cherry picked from commit e7dc0de75e)
The prompt itself may get destroyed when canceled, in which
case it is no longer possible to chain up in the vfunc.
This is usually not an issue as the prompt is only destroyed
at the end of a transition, but it results in a warning if
animations are disabled.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3317>
(cherry picked from commit dac4f2cb86)
gsettings overrides can be in affect when XDG_CURRENT_DESKTOP is set. We
need predictable default values for predictable tests in mutter and thus
mutter will start asserting that GSETTINGS_BACKEND='memory' and
XDG_CURRENT_DESKTOP=''.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3329>
(cherry picked from commit beb3f120dd)
The fingerprint device fetching code has a generic error handler,
that assumes the passed in error is GError. If it's not a
GError it will fail trying to use GError specific methods.
This commit adds some validation checking.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3319>
(cherry picked from commit d8ab090d47)
We no longer provide a portal implementation, so there's no need
for owning the name. Right now only the gnome portal consumes
the API, and that accesses it under "org.gnome.Shell".
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3326>
(cherry picked from commit 9cafdb6d27)
It can be useful to know whether an icon displays a symbolic (rather
than just requesting it). Add a new :is-symbolic property for that
purpose, backed by private API on StImageContent that allows the
texture cache to shuffle that information through to the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
(cherry picked from commit 56cc755bf6)
After the recent notification changes, the title may still be null
when the source is originally added. Handle that case and make sure
we pick up later title changes by setting up a property binding.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
(cherry picked from commit fe24de3ef2)
Adding a notification clearly constitutes a count change, but
the notify call was accidentally dropped during the overhaul
of the notification API.
Fixes: 34f05b075b ("messageTray: Let the tray decide whether to show a
banner")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3308>
(cherry picked from commit 2c43225575)
Sometimes the test runners are saturated with other work. Bump the test
timeouts by a multiplier of 5 with the hope that they now will be much
more likely to have time to finish in time.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3299>
(cherry picked from commit f31099cd85)
The fallback path broke when we removed support for window icons.
Nowadays we track all windows, and as a result should always have an
associated app (although not necessarily backed by a .desktop file),
so this shouldn't make a difference in practice. Not to mention that
external docks (like cairo-dock) are extremely rare themselves now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3295>
(cherry picked from commit 0d571e9191)
Currently we're using relative positioning when sending click events to
tray icon clients, and this leads to some apps (especially Qt ones) to
try to open the menus at such absolute coordinate under X11.
To prevent this to happen, let's get the root coordinate from the xembed
and let's use it to compute the synthetic event root x/y.
We could have even used the actual event position for this, but getting
it from the xembed makes this more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3283>
(cherry picked from commit 794acd65a8)
Override redirect windows manage their own positioning and size alone
and are always sticky, so we're not covering them either with the
animation MonitorsGroup, and thus there's no need to clone them or we'd
end up having two windows painted.
This was causing the shell tray icon window actors (that have no opacity
by default but that are override redirect) to show up during the
animation as their clone animation is not 0.
The other option would be hide them during the animation phase, but
there's no need for this.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3285>
(cherry picked from commit 3a34c16eca)
Even if an invalid syntax doesn't make glib-compile-schemas error out in this
case, ensure the file is valid XML to appease third-party parsers.
Signed-off-by: Gabriel Nagy <gabriel.nagy@canonical.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3281>
(cherry picked from commit a106e52b4f)
Simply looking at the return value of sd_pid_get_user_unit can be used
to determine if the process is in a systemd unit, but it doesn't say if
gnome-shell is managed by systemd.
For example, running toolbx on a host with systemd creates a libpod
unit, even if the gnome-shell that gets started in the toolbx is itself
not managed by systemd.
We can make sure that gnome-shell is managed by systemd simply by
checking if the unit we're running starts with org.gnome.Shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3267>
(cherry picked from commit b3580919e3)
