Under certain unknown circumstances currently not every
`disable_unredirect_for_display()` gets matched with an
`enable_unredirect_for_display()` when closing the overview.
As we only want to not disable unredirection when hidden and we nowadays
have a state machine that ensures we transition to and from one state to
another only once, handle unredirection en-/disablement as part of the
state transition.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2970>
(cherry picked from commit a94fcee961)
IBus requires XAUTHORITY and XDG_RUNTIME_DIR to be able to spawn its XIM
implementation correctly. Using launch context to get environment can correctly
launch on non-systemd setups.
Closes: #6998
Signed-off-by: xiaofan <xiaofan@iscas.ac.cn>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2947>
(cherry picked from commit 050d0e10c7)
Reportedly, non-alphanumeric key levels were able to stick by
happenstance, and let the user press multiple keys until explicitly
switching to a different mode. Reportedly, this broke, switching to
the default level after the first key press on the additional levels.
Since we have this information in the OSK key models (each level has
a "mode" field to either default/latched/locked), retrieve this
information for them for each level, and only reset to the default
level if on one of those latched levels, and the relevant key was not
locked through long-press.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
(cherry picked from commit bc3b890e75)
The _commitAction() paths have early returns, which made resetting the
latched mode inconsistent depending on the paths taken to commit the
string. This made latched modes not return to normal on e.g. Shell
entries.
Make this happen outside the function, and after the only calling
point, so that the level is correctly reset on all situations.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2945>
(cherry picked from commit 08f3ad3835)
The window button is disabled when
- there are no windows
- we are in screen-recording mode
- the session mode doesn't allow windows
However the last condition is only taken into account when
opening the dialog, but not when switching from recording-
to screenshot mode.
Address this by updating the button's sensitivity in a separate
function, so the different conditions are considered consistently.
Closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6990
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2944>
(cherry picked from commit 521525948e)
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 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)
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>
