Carlos Garcia Campos authored Oct 28, 2016 and Jeremy Bicha committed Oct 29, 2016

The Mozilla documentation says: "And as always when working with
reference counted NPObjects, the caller is responsible for calling
NPN_ReleaseObject on the NPObject to drop the reference."

Browsers assume that the plugin does the right thing and always call
NPN_ReleaseObject. At some point the object is released and deallocated
and both the plugin and browser still have references to the object
thinking that it's still alive. That's why the crash is sometimes in the
plugin when it tries to use the np object, and sometimes in the browser.

https://bugzilla.gnome.org/post_bug.cgi

Update NEWS.

While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible

https://bugzilla.gnome.org/show_bug.cgi?id=765061

https://bugzilla.gnome.org/show_bug.cgi?id=765061

If cogl_framebuffer_allocate fails in _st_create_shadow_pipeline_from_actor, the
CoglOffscreen* that was allocated earlier in the function is leaked.

https://bugzilla.gnome.org/show_bug.cgi?id=735705



Signed-off-by: Aaron Plattner <aplattner@nvidia.com>

Christophe Fergeau authored Dec 20, 2015 and Michael Catanzaro committed Mar 21, 2016

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

Note: This is needed to avoid crashes with libsecret 0.18.4 -- Michael

Florian Müllner authored Mar 08, 2016 and Michael Catanzaro committed Mar 16, 2016

While a channel has pending messages, it will pop up again when
dismissed. That is clearly not what users expect, so clear them
out first before closing a channel.

https://bugzilla.gnome.org/show_bug.cgi?id=747991

Update NEWS.

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
  Netw...

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

Generally a user-changed operation will be uninteresting, but if the
user is currently in the user list and the account changes to locked, we
want to remove it from the list, or if the user is not in the list and
the account changed to unlocked, we want to add it to the list. This
fixes the case where a new user account created in gnome-control-center
does not appear in the user list. The password mode is set in the new
account immediately after it is created, but the operations are not
atomic, so the login dialog considers the new user account when it is
still locked and rejects it from being displayed, then immediately
afterwards the account is unlocked. This commit causes the login dialog
to show the account when this occurs.

The containsUser() check here is not strictly necessary, but reduces
spurious calls to addUser() and removeUser(), since there's no easy way
to check if the locked status of the account has changed (as it's much
easier to connect to one signal on the UserManager than to
notify::locked on each User object).

https://bugzilla.gnome.org/show_bug.cgi?id=758568

We need to take the scale factor into account to avoid tiny window
previews on HiDPI.

https://bugzilla.gnome.org/show_bug.cgi?id=758676

LoginDialog has a private _user, but UserListItem has a public user.
Easy to get wrong since _user would be the right thing to type in 90% of
this file.

Update NEWS.

Carlos Garcia Campos authored Nov 17, 2015 and Michael Catanzaro committed Nov 17, 2015

Merge PluginData and PluginObject structs into a single one and create
the scriptable object associated to the plugin instance in NPP_New. Then,
when NPPVpluginScriptableNPObject is requested we just return the
scriptable object associated to the given instance. This caused the
crashes in NPN_InvokeDefault with WebKit, since we had multiple
scriptable objects for the same instance, but only one of those objects
had the onchange listener installed. Firefox seems to cache the
scriptable object for the instance and therefore NPPVpluginScriptableNPObject
is requested only once.

https://bugzilla.gnome.org/show_bug.cgi?id=737932

Carlos Garcia Campos authored Nov 11, 2015 and Michael Catanzaro committed Nov 17, 2015

NPAPI plugins are windowed by default, so we need to set
NPPVpluginWindowBool value to FALSE on startup. This way the browser
will not create a GtkSocket for a GtkPlug that we are not going to
create. It doesn't make sense to claim that we need XEmbed either.

https://bugzilla.gnome.org/show_bug.cgi?id=757940

This reverts commit a52c91e9.

https://bugzilla.gnome.org/show_bug.cgi?id=758035

Update NEWS.

Carlos Garcia Campos authored Nov 11, 2015 and Carlos Garcia Campos committed Nov 12, 2015

NPAPI plugins are windowed by default, so we need to set
NPPVpluginWindowBool value to FALSE on startup. This way the browser
will not create a GtkSocket for a GtkPlug that we are not going to
create. It doesn't make sense to claim that we need XEmbed either.

https://bugzilla.gnome.org/show_bug.cgi?id=757940

The result of subtracting unsigned operands is unsigned, which throws
off our calculation in case it should be negative.

This partly reverts 18b6f133.

https://bugzilla.gnome.org/show_bug.cgi?id=757779

Carlos Garcia Campos authored Nov 07, 2015 and Carlos Garcia Campos committed Nov 10, 2015

This ensures that the module will not be unloaded, since GObject types
registered statically can't be reloaded. This should fix crashes with
browsers that correctly unload the plugins.

https://bugzilla.gnome.org/show_bug.cgi?id=737932

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

Adds the missing checks for whether we should toggle the overview, on
button and key release.

https://bugzilla.gnome.org/show_bug.cgi?id=756925

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=1206754

https://bugzilla.gnome.org/show_bug.cgi?id=756983

It's very unexpected that a spinner animation would
preempt idles from running.

This commit runs the spinner animation with a low
priority to ensure it doesn't take over the main
loop.

https://bugzilla.gnome.org/show_bug.cgi?id=754814

Right now the spinner animation updates every 14ms.
60 frames per second would be one frame per 16.667ms,
so we're waking up more frequently than we need to.

This commit changes the wakeup to happen after 16ms.

https://bugzilla.gnome.org/show_bug.cgi?id=754814

There's no point in delaying the emission.  We should do it
right away.

https://bugzilla.gnome.org/show_bug.cgi?id=754814