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
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
Since commit 48a54e8ac4, paint() has an explicit framebuffer parameter,
however a couple of submethods are still using the draw framebuffer,
which breaks when rendering to an offscreen buffer.
The polkit agent does not take ownership of the request's cancellable,
so it may no longer be valid after the request finished and we need
to disconnect it before that. Before the GTask port in 8b4249ef2,
it was safe to do that when freeing the request data because requests
completed in an idle, but now we need to do it before returning the
task result.
https://bugzilla.gnome.org/show_bug.cgi?id=757668
If we are trying to render a shadow at a size that is very large in one
direction, but small in the other direction (so that we don't 9-slice
the texture), then allocating the backing texture for the offscreen
buffer may fail due to texture-size limits. Don't crash in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=757150
There are quite a few crashes in retrace.fedoraproject.org that are a result of
of cairo_pattern_get_surface() failing, then a subsequent call to
cairo_image_surface_get_width() crashing because no surface was returned to the
out parameter. Knowing what causes these is hard - my best guess is widgets getting
allocated at ridiculous sizes - but avoiding the crash makes sense in any case.
See https://bugzilla.redhat.com/show_bug.cgi?id=1206754https://bugzilla.gnome.org/show_bug.cgi?id=756983
The text-scaling-factor GSetting was not being properly propagated
to clutter and the Pango font map; under X this is done by Clutter,
which listens to XSETTINGS directly.
https://bugzilla.gnome.org/show_bug.cgi?id=756447
gdk_window_set_composited() is deprecated, and we don't need it as
we end up setting it to the default anyway.
We do need gtk_widget_set_double_buffered() though, which has been
deprecated as well because it is only meaningful on X11 - but so
is XEmbed, so just shut up that warning.
Composite is a hard requirement for mutter's compositor, so if we get
to the point of managing the tray, we already know that the extension
is supported. So let's get rid of yet another deprecation warning.
It has been deprecated for a while in favor of GdkRgba, though in our
case translating ClutterColors to an intermediate color type before
setting _NET_SYSTEM_TRAY_COLORS is a bit silly, so just move to
ClutterColor as the rest of the code base.
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
Both ShellAppSystem and ShellTrayManager are used as singletons, which
significantly reduces the usefulness of inheritance - it's unlikely for
extensions to inherit from them anyway (AND use any of the vfuncs), so
drop them to allow defining the types as final in an upcoming commit.
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
They are unused, as we don't use them ourselves and the class is not
exposed to introspection. Drop them to allow defining the type as final
in an upcoming commit.
There is nothing preventing callers from replacing the internal
layout manager, and as long as the replacement is a (or derives
from) ClutterBoxLayout, everything should work fine except for
losing a bit of automatic property mapping - and the latter is
easily fixable by moving the setup out of the constructor.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
We use the newly introduced feature from Mutter to hook up our own
fullscreen and unfullscreen animations.
To give the illusion of a transition as smooth as possible, we create a
snapshot of the current contents of the actor before its state is
changed, and crossfade between the two states while the size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=707248
The JS code could still be holding on to a reference to a window-backed app
after all windows have vanished. (For example, the dash queues an idle to
refetch apps and display them.) Avoid dying with an error message if we
attempt to activate or otherwise manipulate such a window.
https://bugzilla.gnome.org/show_bug.cgi?id=674799
The default pipeline color is opaque white and blending is turned
off. If we only draw with that color (e.g. because animations are
disabled and we're always drawn with opacity == 255), blending is kept
disabled since cogl_pipeline_set_color() returns early if the color
doesn't change from what was there before.
In our case we always want blending to be enabled which we can achieve
by setting the blending string ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=755827
Since commit 4f1f226828 we only consider buttons clicked when the
release event had a corresponding press event. However as we use
the hover state to check whether a release event actually occurred
on the button, we dismiss any clicks in cases where we missed the
enter event - most likely due to some other actor holding a grab.
Instead, check whether the button contains the event's source, which
should be less error-prone.
https://bugzilla.gnome.org/show_bug.cgi?id=748919
GObject-Introspection started warning for wrong annotations, and
StGenericAccessible::set-current-value has a return value annotation
even if it returns nothing. This generates the warning:
src/st/st-generic-accessible.c:146: Warning: St:
StGenericAccessible::set-current-value: invalid return annotation
Which, coupled with fatal warnings, breaks the Shell build.
