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
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
Any time estimates we can come up with are notoriously unreliable;
even on devices that report correct (dis)charging rates, any change
in workload, screen brightness etc. can throw our estimate off by
a huge amount. This is further compounded by bad firmware and battery
firmware which reports inaccurate data as neither Windows nor Android do
not use that data.
So instead, limit ourselves to only showing the current percentage
and leave its interpretation to the user.
As an added bonus, we end up with shorter strings that are less likely
to cause problems with ellipsization when translated.
https://bugzilla.gnome.org/show_bug.cgi?id=708472
Builtin chat and network notifications already follow the notification
policy of appropriate applications, it makes sense to do the same for
autorun notifications to give users control over hotplug notifications
in Settings.
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 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
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
We can autodetect what to do based on the user's session, so drop
the separate desktop files.
This, along with some future changes, will enable us to be bus
activatable.
https://bugzilla.gnome.org/show_bug.cgi?id=741666
If we detected that Bluetooth devices were setup, show the Bluetooth
menu so that users can easily turn Bluetooth back on.
This is a bit of a hack, as we cannot detect whether there is a
Bluetooth adapter at all when it's disabled, so we cannot tell whether
there were any Bluetooth devices setup, at some point. This state is
saved in the gnome-shell GSettings in the had-bluetooth-devices-setup
key.
Checking whether we saw Bluetooth devices at one point is a good
enough guess of whether there will be some in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=723848
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
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
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
If the source actor is sized 0x0, the grabHelper will close the menu
on button release if the menu ends up flipped because in that case the
release event happens when the pointer is neither over the source
actor (since it's 0x0) or over the menu actor. A zero sized source
actor works for the non-flipped menu case because the menu's actor
itself ends up underneath the pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=756605
If we get another effect on the same actor, we should make sure to
remove the clone through the "overwrite" methods provided by Tweener, or
there will be a race that might end up with a stray clone being left
around.
https://bugzilla.gnome.org/show_bug.cgi?id=756714
The translation should describe the difference between the fullscreened
and unfullscreened position of the window - however we are currently
assuming a fullscreen position of (0, 0) instead of the monitor's origin,
which causes glitches on dualscreen setups.
https://bugzilla.gnome.org/show_bug.cgi?id=756697
