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)
NetworkManager frequently refreshes the list of available access points.
For some reason this often ends up removing some or all access points
only to add them back in a later refresh later. With the exception of
the currently connected access point, which is never removed.
When all access points of a WirelessNetwork have been removed, it gets
destroyed by NMWirelessDeviceItem::_removeAccessPoint(). This however
does not happen for the currently connected network due to the always
present access point. If this network now happens to consist of multiple
access points, the "unused" NMAccessPoints will get removed and added
in these refreshes, without the WirelessNetwork getting destroyed.
Whenever such an unused access point is added, due to the use of signal
tracking this leaks the NMAccessPoint and SignalTracker until the
WirelessNetwork is destroyed.
However when the NMWirelessDeviceItem is destroyed, for example due to
suspending, it stops tracking access point changes, ensuring that the
condition for the WirelessNetwork being destroyed can not occur anymore.
Even with just two access points, such as can be found in 2.4GHz+5GHz
home routers this issue leaks hundreds of NMAccessPoints and
SignalTrackers per day. As well as a small number of WirelessNetworks
which are also kept alive by the SignalTrackers.
To fix this disconnect from the access point when it gets removed and
destroy all remaining networks when the NMWirelessDeviceItem is
destroyed.
(cherry picked from commit feb1c57dde)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2704>
Switching between the app grid and the window picker in the overview via
gestures results in _gestureEnd() getting called with endProgress !== 0
in both cases, which leads to it calling _showDone(). This then
unconditionally changes the state to SHOWN, which in this situation is
already the current state. Since the previous commit this results in a
warning, so check if we are already in the SHOWN state.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
(cherry picked from commit f5d793647b)
There have been several bugs in the past that caused invalid transitions
of the `shown` state, such as going from `showing` to `showing`. These
cause consecutive emissions of the `showing` signal, which can confuse
other classes such as the search controller which connects to the stage
`key-press-event` on showing and disconnects again on `hiding`. Having
two consecutive `showing` signals will cause it to connect twice, and
only disconnect once when hiding the overview again. This will lead to
key presses getting repeated in the search until the session is
restarted. Because there is no obvious connection to how and when this
issue got triggered, this now adds some validation code that only allows
valid transitions and throws an error otherwise so we get a backtrace of
the code actually causing the problem.
This does not fix the issue(s) causing the invalid state transitions, it
only adds a way of tracking them down.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4651
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2514>
(cherry picked from commit a91b6439ba)
Device additions/removals are tracked by GvcMixerControl, which
doesn't change when unsetting the stream. So clearing the menu
manually was a workaround, not a fix.
It's also worth noting that I failed to reproduce the original
issue again, so it's possible that we were working around a
pipewire bug that has since been fixed.
This reverts commit 1b62b7ea0a.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616>
(cherry picked from commit 3de828cc60)
Since commit 7bd98f3f5f animateOutAndDestroy() destroys
the placeholder right away when animations are disabled. Connect to the destroy signal
before calling the function.
This fixes the following error:
Gjs-CRITICAL **: 16:51:35.195: Object .Gjs_ui_dash_DragPlaceholderItem (0x55b9a946da20),
has been already disposed — impossible to connect to any signal on 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 0x55b9a70d08f0 ==
#0 7ffe161bd070 b resource:///org/gnome/shell/ui/dash.js:835 (df3d61d32e0 @ 98)
#1 7ffe161bd170 b resource:///org/gnome/shell/ui/dash.js:901 (df3d61d33d0 @ 779)
#2 7ffe161bd290 b resource:///org/gnome/shell/ui/dnd.js:562 (3d4da0cfd420 @ 909)
#3 7ffe161bd360 b self-hosted:1115 (3d4da0c7ef10 @ 407)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2604>
(cherry picked from commit 325755e1c3)
Dropping a icon from the dash to the application grid will set this._placeholder
to null. However the AppIcon is still used to represent the application in the
application grid. If we click on it we emit a pressed event. Stop assuming
that this._placeholder is still valid in the callback, use the icon parameter
instead.
This fixes the following error:
```
Gjs-CRITICAL **: 18:22:39.003: JS ERROR: TypeError: this._placeholder is null
_ensurePlaceholder/<@resource:///org/gnome/shell/ui/appDisplay.js:1477:17
vfunc_button_press_event@resource:///org/gnome/shell/ui/appDisplay.js:3121:27
```
Fixes: 6fc93b78bc
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6317
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2606>
(cherry picked from commit ec6ab60e62)
The videos directory doesn't necessarily have to exist, users are free to
delete it. Right now we don't handle this case and screencasting fails.
Let's handle it and fall back to the users home directory instead when
xdg-videos doesn't exist.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2594>
If we are getting purpose hint changes while the language switcher is popped
up, this likely means the purpose hint was actually triggered by the key
focus change induced by the language switcher popping up.
In this case, we on one hand would like to preserve the state that applied
before thise focus change, and on the other we very much want to avoid the
keymap change that would forget about the keys being pressed.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6066
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2534>
The nPages property can be 0, which is the case in a stripped down CI
image without a single app to be listed, which means we can't clamp to
`nPages - 1`, since that'll give us a negative index and the following
error:
(gnome-shell:266): Gjs-CRITICAL **: 16:48:56.633: JS ERROR: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1236:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1582:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:499:18
_init/pagesChangedId<@resource:///org/gnome/shell/ui/iconGrid.js:1137:24
_removePage@resource:///org/gnome/shell/ui/iconGrid.js:454:14
_removeItemData@resource:///org/gnome/shell/ui/iconGrid.js:495:18
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:854:14
moveItem@resource:///org/gnome/shell/ui/iconGrid.js:1277:29
_moveItem@resource:///org/gnome/shell/ui/appDisplay.js:1194:20
_redisplay/<@resource:///org/gnome/shell/ui/appDisplay.js:1085:22
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1080:17
_redisplay@resource:///org/gnome/shell/ui/appDisplay.js:1370:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:633:24
_initializeManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:95:14
async*_init@resource:///org/gnome/shell/misc/parentalControlsManager.js:63:14
ParentalControlsManager@resource:///org/gnome/shell/misc/parentalControlsManager.js:55:4
getDefault@resource:///org/gnome/shell/misc/parentalControlsManager.js:42:22
start@resource:///org/gnome/shell/ui/main.js:184:29
@resource:///org/gnome/shell/ui/init.js:6:17
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
(cherry picked from commit 367d40d31b)
Running dispose on the setting causes issues when we're being destroyed,
as the signal handler in the GSettings binding will be cleared by the
GObject itself before it has the chance, resulting in warnings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
(cherry picked from commit fa47a7576d)
Since commit 7bd98f3f5f the onComplete callback
is called right away when animations are disabled. As side effect, now
this._coverPane gets shown/hidden in the wrong order. Start the animation after
setting this._coverPane initial state, so that the animation callback can set the
this._coverPane final state without it being overwritten later.
Move the animation also after emitting the showing and hiding signals. So that the
order showing -> shown and hiding -> hidden is still preserved when animations are
disabled.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6096
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2532>
(cherry picked from commit cf47b4a347)
We currently initialize regions in all code paths except for the
greeter. But while there are no windows on the login screen, the
work area can still be used for positioning, for example for
notifications.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2546>
(cherry picked from commit 990cdbd134)
We assign (disambiguated) device names every time a device is added
or removed, and store the name on the corresponding menu item.
However menu items are only created when the device should be shown,
not necessarily when it is added (unplugged ethernet cable, ongoing
initialization, ...).
Fix this by tracking device names separately from device items, and
set the name on newly created items.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6040
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2529>
(cherry picked from commit b2ff25b31d)
If the OSK is destroyed while visible without being close()'d first,
the completion mode might remain turned on. Ensure it is turned off
on OSK destruction so that typing-booster has no chance to remain
turned on.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
(cherry picked from commit a33e3eaf22)
Even though the emoji panel may be destroyed with the OSK, the swipeTracker
that is set up to navigate between pages is left lingering, and handling
events for some gestures in the stage. This results in warnings like:
JS ERROR: TypeError: this._panel is null
set delta@resource:///org/gnome/shell/ui/keyboard.js:720:9
_onSwipeUpdate@resource:///org/gnome/shell/ui/keyboard.js:750:22
_updateGesture@resource:///org/gnome/shell/ui/swipeTracker.js:670:14
vfunc_gesture_progress@resource:///org/gnome/shell/ui/swipeTracker.js:288>
on touch interaction after the OSK was shown and dismissed. In order to fix
this, issue explicit destruction of the swipeTracker when the emoji pager
actor is destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2543>
(cherry picked from commit 7e4f7c7e5b)
When the overview is hidden just after starting GNOME Shell the app
grid is not populated yet. Thus, this._grid.nPages is 0. When the
overview is about to be hidden, we call goToPage(0) on the AppGrid.
This results in pageNumber being clamped to -1 and leads to the
following exception:
```
JS ERROR: Exception in callback for signal: hidden: Error: Page -2 does not exist at IconGrid
getItemsAtPage@resource:///org/gnome/shell/ui/iconGrid.js:1383:19
_translatePreviousPageIcons@resource:///org/gnome/shell/ui/appDisplay.js:323:34
_syncPageIndicators@resource:///org/gnome/shell/ui/appDisplay.js:396:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:445:14
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1237:29
goToPage@resource:///org/gnome/shell/ui/appDisplay.js:1584:15
_init/<@resource:///org/gnome/shell/ui/appDisplay.js:1328:52
_emit@resource:///org/gnome/gjs/modules/core/_signals.js:89:42
_hideDone@resource:///org/gnome/shell/ui/overview.js:589:18
_animateNotVisible/<@resource:///org/gnome/shell/ui/overview.js:566:55
onStopped@resource:///org/gnome/shell/ui/overviewControls.js:753:21
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:150:22
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:316:60
```
Connect to the overview hidden signal only after initializing the
AppDisplay content, so that goToPage(0) is not called when there
is no page yet.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5837
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2536>
(cherry picked from commit 2326721561)
