Prior to Geoclue v2.7, the location description did not seem to ever be
set. Now, the source used to determine the location is set as the
description. This can result in the location name in dateMenu to be set
as "WiFi", "GeoIP", etc., since we relay the description as the location
name to GWeather. Instead, pass an empty string so GWeather continues
to set the location name itself.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2729>
(cherry picked from commit ae86b58d59)
Commit 17d9ec5788 made the input method call update() more eagerly,
but also at times that it does not have a cursor position yet. Make
it bail out correctly in that situation.
Fixes: 17d9ec5788 ("inputMethod: Keep Capabilite.FOCUS before context.focus_in/focus_out")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2876>
(cherry-picked from commit 5e36a06835)
If context.focus_out() is called *after* context.set_capabilities(0),
The FocusOut D-Bus method is ignored because of no FOCUS capability.
If context.focus_out() is called *before* context.set_capabilities(0),
The 0 capability is set to the next focused context and the
FocusIn D-Bus method is ignored because of no FOCUS capability.
So context.set_capabilities(0) should not be called.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6415
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2666>
We currently throw an error when encountering a result that cannot
be represented as string, with the prompt appearing somewhat stuck
(the input cannot be committed).
Showing a lame fallback instead at least avoids that issue. When
the object has a typeof 'object' but is not an instanceof Object,
we are likely dealing with an ES module, and can show a slightly
less lame fallback.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2842>
(cherry picked from commit 03025d7cff)
We currently only find a matching ref on the same remote in
a merge request pipeline, but not in branch pipelines.
It can occasionally be useful to run a pipeline without opening
a merge request, so try the same remote here as well instead of
just assuming origin.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2814>
(cherry picked from commit dbc9ebc6ab)
We currently special-case the DISABLED error when initializing
filtering, but not on app filter changes.
While it seems reasonable that Malcontent.Manager wouldn't emit
the signal while disabled, that's not actually true: It is emitted
when any user account information tracked by AccountsServices
changes.
Even if the signal were limited to changes of the ParentalControls
extension, it would still get emitted when app filtering *becomes*
disabled.
So regardless of potential improvements in libmalcontent itself,
we should filter out the DISABLED consistently, both when creating
the initial filter and when updating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796>
(cherry picked from commit 593f659a73)
Commit c449058d44 changed the pointer clone to use a single
actor. However that broke applying the hotspot translation to the
position, so the magnified cursor is now displayed with a shift.
Undo the change to restore the old behavior.
This reverts commit c449058d44.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2780>
(cherry picked from commit ae24b0247e)
The IBusCandidatePopup can get 'stuck' in an active, visible state if
it is on-screen at the point when the input method is changed to a method
that doesn't use such popup (e.g. regular English).
Force the candidate popup to close when the engine is changed.
It will reappear (via regular lookup table update signal) if/when it is
next required.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6717
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2774>
(cherry picked from commit fa34d30d3e)
The callback would schedule a clutter_actor_destroy() on the first
argument. Unless told otherwise, this is the same actor that is
already being destroyed, so this is a no-op.
Instead, the intent is to make the clone follow up destruction of
the window actor so that it results in correct removal of this
window from the ShellWindowPreviewLayout. Use a swapped connection
to pass the clone actor as the first argument of the signal callback.
Fixes: 04c781674c ("Move WindowPreviewLayout from JS to C")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6570
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2756>
(cherry picked from commit 356bab1121)
Both the subdir and prepare arguments are very specific to
building the extensions-tool subproject stand-alone. In order
to make the script more generic, turn those required arguments
into optional --subdir and --prepare ones.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
(cherry picked from commit ea629cabbf)
We currently remove the directory at the end of the script, but
that code is only reached when all previous operations were
successful.
Address this by first using an absolute directory path in /tmp
instead of a "random" location based on the CWD, then set a trap
to remove it on exit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
(cherry picked from commit fac05b182c)
The script has four mandatory arguments, and also accepts optional
build options that are passed on to meson. Checking for the number
of arguments *before* filtering out the optional ones means that
`./install-meson-project.sh -Done=1 -Dtwo=2 -Dthree=3 -Dfour=4`
is considered valid, even though not a single required argument
is passed.
Fix this by filtering out the arguments before doing the usage
check. As it is a nice touch to have usage information at the
top of the script, move the message into a usage() function at
the top.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2712>
(cherry picked from commit 919812a851)
If we have multiple desktop ID's that share the same startup-wm class
and none of them is actually matching the desktop-id, then we should
exclude the ones that should not be shown in the current desktop.
This will help preventing cases such as the previous one in case no
desktop file ID would match the startup-wm-class exactly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
(cherry picked from commit 12bb3a601d)
When fetching the desktop ids into a map of startup-wm classes we meant
to give the ones that match the desktop ID more priority, however
this did not happen because we were always comparing a desktop
file id, including the `.desktop` suffix, with a wm-class that generally
does not include that.
This is the case of gnome-system-monitor, that provides two desktop
files, one of which is OnlyShowIn=KDE but both have the same
StartupWMClass and thus the first parsed is preferred, even though its
desktop-id is gnome-system-monitor-kde.
As per this, remove the .desktop suffix when comparing it with the
startup-wm-class, keeping the old check just in case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
(cherry picked from commit e7a09946ca)
When a WindowPreview is being destroyed, the class default handler for
the `destroy` signal is responsible for destroying its child actors.
This happens after the emission of the `destroy` signal, i.e. after
`WindowPreview::_onDestroy()` has been run.
The destruction of the WindowPreview's child actors now triggers a
re-pick, but due to WindowPreview having already being marked as
`CLUTTER_IN_DESTRUCTION`, it will not be picked, resulting in a `leave`
event if the cursor was on top of the WindowPreview at the time
`destroy()` was called on it.
So this leads to `WindowPreview::vfunc_leave_event()` being run after
`WindowPreview::_onDestroy()`, which means the idle started by the leave
event handler will not be removed and ends up accessing actors after
they have already been destroyed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5512
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6065
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2738>
(cherry picked from commit 4bbf6d497d)
Dash labels are children of the main uiGroup and so could be destroyed
before their logical-owner DashItemContainer during shutdown.
This implies that we could destroy them twice. To avoid this, unset them
when destroyed.
This is mostly visible when using dash-to-dock, but it's still
technically possible with upstream code:
** Message: 19:57:49.847: Shutting down GNOME Shell
(gnome-shell:2788214): Gjs-CRITICAL **: 19:57:49.933: Object St.Label
(0x55b33668eab0), has been already disposed — impossible to access it.
This might be caused by the object having been destroyed from C code using
something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55b3345fd3d0 ==
#0 7ffeabd810d0 b /data/GNOME/gnome-shell/js/ui/dash.js:86
#1 55b335b62f88 i /data/GNOME/JHBUILD_HOME/.local/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/docking.js:487
#2 7ffeabd838f0 b self-hosted:1121
#3 55b335b62ec8 i /data/GNOME/gnome-shell/js/ui/layout.js:240
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2739>
(cherry picked from commit 8bf06bfc9f)
The left/right navigation between top bar buttons is usually
handled by a key-press handler on the button's menu.
However when a DummyMenu is used, the button itself serves as
fake menu actor and will get grabbed when "opening" the menu.
Due to that grab, the event is not propagated to the stage,
and regular keynav does not work.
To avoid the focus getting stuck in that case, add an explicit
key-press handler that bypasses the grab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2734>
(cherry picked from commit ecb274cee0)
When the user clears all notifications from the notification menu UI, it's
possible for a queued notification to be destroyed after the currently displayed
notification. The removal of the currently displayed notification is not
processed until the notification menu is closed (due to `this._bannerBlocked`).
By then, it's possible that `_notificationRemoved` has already been overwritten
when `_onNotificationDestroy` is invoked with another (queued) notification.
This eventually results in a notification banner that cannot be removed by the
user as the notification object needed to do so has already been destroyed.
Fix this by only assigning to `_notificationRemoved` if `this._notification ==
notification`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2736>
(cherry picked from commit cde7d44a28)
Emitting this signal is broken right now: We check for a length of 0 on
this._objects[objectPath], but the
`this._objects[objectPath][interfaceName] = null` we do before the
check doesn't actually remove the key, it only sets the value to null,
leaving the key around and thus the amount of entries in the object doesn't
change.
Fix that by using the delete statement instead, "delete" properly removes
the key and thus affects the amount of entries in the object, making our
length === 0 check effective.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2730>
(cherry picked from commit 8431e7ae51)
When a window is in the background and should not have the cursor on top
of it, its _cursor will be null. By getting the texture through it, we
add this extra check, which was missing before, leading to a cursor
drawn at 0, 0 on windows where it should not have been drawn.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2702>
(cherry picked from commit 237c3e958d)
In GNOME OS, due to a misconfiguration, geoclue was configured without
systemd support. In that configuration, geoclue does not install its
systemd .service file (geoclue.service) but it (incorrectly) includes
the following line in its D-Bus service file:
SystemdService=geoclue.service
As a result, when dbus-daemon tried to activate it at gnome-shell's
request, it would fail with:
Unit geoclue.service not found
Then, GeoclueAgent._onGeoclueVanished() would be called, as the
name_vanished_handler passed to Gio.bus_watch_name(). This is consistent
with Gio.bus_watch_name()'s documentation:
> You are guaranteed that one of the handlers will be invoked after
> calling this function.
But that function assumed that this._managerProxy is defined, leading
to:
JS ERROR: TypeError: this._managerProxy is undefined
_onGeoclueVanished@resource:///org/gnome/shell/ui/status/location.js:163:9
Fix this by checking for nullishness of this._managerProxy. (Strictly
speaking, it's undefined rather than being null, but other code in this
file already uses the vaguer '!= null' test, which considers undefined
to be null.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689>
(cherry picked from commit ab0c795e81)
909616b208 seems to have wrapped window actors in a container, so the actor.has_pointer check started failing. Instead, switch to meta_window_has_pointer () which doesn't rely on window actor implementation details.
We check for existence of has_pointer first just in case someone attempts to run gnome-shell 44.1 with mutter 44.0 which does not have the function exported publicly yet.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2710>
(cherry picked from commit 4daea0ccae)
