Only recent IBus versions have support for this signal
which is used for wayland clients. In order to work
with older IBus versions we can silently ignore the
signal's absence.
https://bugzilla.gnome.org/show_bug.cgi?id=753476
We lost media controls outside of notification banners when
implementing the new notification designs. Reimplement this
functionality as a dedicated "Media" section in the message
list based on MPRIS.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
Currently both the base classes for messages/sections and the message
list itself that instantiates the available sections are located in
the same module. As a result, it isn't possible to define sections
in a different module without introducing circular dependencies. The
Calendar module is already unwieldily large, so split it up a bit to
avoid it growing even bigger in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=756491
It is not always possible to determine the type of audio device that
got plugged in. Add a system modal dialog to query the user in that
case and export in on the bus to gnome-settings-daemon.
https://bugzilla.gnome.org/show_bug.cgi?id=760284
IBus now provides a new method for cursor positioning where the
coordinates are relative to the focused window. This is useful for
wayland clients which don't have access to their global coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=753476
We are already emitting a 'drag-end' signal when no more dragging
is happening, so it makes sense to emit a 'drag-begin' too when
starting, so that apps interested in implementing different logic
between those two events can easily do it without needing to deal
with the underlying 'button-press-event' signal for the actor.
https://bugzilla.gnome.org/show_bug.cgi?id=761208
The non-interactive requests for 'vpn' settings are forwarded to the UI because
it is able to talk to the auth helpers. However, the VPN requests are identified
by the connection type instead of setting type. That is incorrect and the UI
is not prepared to handle such requests; tries to construct a dialog and fails
miserably:
Gjs-Message: JS LOG: Invalid connection type: vpn
(gnome-shell:13133): Gjs-WARNING **: JS ERROR: Error: No property 'text' in property list (or its value was undefined)
NetworkSecretDialog<._init@resource:///org/gnome/shell/ui/components/networkAgent.js:60
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_Base.prototype._construct@resource:///org/gnome/gjs/modules/lang.js:110
Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:204
NetworkAgent<._handleRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:724
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NetworkAgent<._newRequest@resource:///org/gnome/shell/ui/components/networkAgent.js:715
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=760999
This never worked since the code landed but apparently no-one noticed
until now.
The intent here is to return the accessible's default role if none has
been explicitly set on the StWidget instance.
https://bugzilla.gnome.org/show_bug.cgi?id=760945
Commit ffe4eaf00d changed this code to
call st_widget_get_accessible_role() instead of using the value
directly which would be an infinite recursion if that function didn't
have a bug. As it is, this just resulted in
CRITICAL **: atk_object_get_role: assertion 'ATK_IS_OBJECT
(accessible)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=760945
The Next and Sign In buttons are disabled when the username/password
field is empty. However, the user can still bypass this button by
pressing the enter key, leading to some odd glitches with the log in
for 'Not Listed?' users.
This is easy to fix by simply not progressing to the next screen when
the button is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746180
In get_secrets_keyring_cb, we own a ref on the 'attributes' hash table
from secret_item_get_attributes), and a ref on the 'secret' object (from
secret_item_get_secret(), but in the SHELL_KEYRING_SK_TAG case, we unref
these once before breaking out of the loop, and the second time after
breaking out of the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=759708
Before reenabling all extensions, we update the list of enabled extensions
to catch any changes that happened while extensions were enabled. However
this is currently broken as onEnabledExtensionsChanged() is a nop while
disabled, so just call getEnabledExtensions() directly.
