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
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
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
Quite tempted to delete this unmaintained and unreliable plugin, but I
can stand it not working so long as it at least stops crashing, so let's
try this first.
Hopefully mitigates bug #737932.
Instead of using the 'extension-state-changed' signal to relay errors,
use DBus's native error mechanism to inform the method caller that the
call has failed. This requires making the method actually asynchronous
so that we don't block the browser, which is stuck waiting for a reply
from the browser plugin. To ensure this, we need to modify the browser
plugin API to ensure its extesion installation method is asynchronous.
Additionally, this lets us remove the awful, broken hacks that we used
when a user clicked the "Cancel" button, replacing it by a DBus return
value.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Since we're going to move to a much more complicated (async!) solution
in a little bit, we're going to require a lot more machinery to handle
that. To help with that, let's rework invocation dispatch so that it's
more generic. Introduce a parse_args system similar to gjs_parse_args,
use X Macros to help with the repetitive parts of the method dispatch.
This shouldn't cause any API breaks, so API_VERSION should still be 4.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Instead of using g_strndup to copy the NPString that gets passed to us
by the plugin host, just use the equally-as-good NPString directly. We
still need to copy the string when passing it over DBus, as there's no
easy way to construct a string GVariant from a length-prefixed string.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
While most browsers use GTK+ on GNOME in some fashion, Opera and
Konqueror do not. We need to explicitly initialize GType before
the browser plugin works properly.
While it's extremely unlikely that document.location would not be an
object in the browser setting, this check is incorrect and we could
possibly crash an NPAPI host if this is the case.
https://bugzilla.gnome.org/show_bug.cgi?id=670489
Add two new APIs, "launchExtensionPrefs" to let SweetTooth let the user
launch the extension preferences tool directly from the browser. To allow
SweetTooth to check if an extension can be configured, add a new key to
the 'metadata', 'hasPrefs', which is returned by the GetExtensionInfo/
ListExtensions DBus methods.
https://bugzilla.gnome.org/show_bug.cgi?id=668429
Some plugin hosts may have junk after the UTF8Characters that we need to strip
off. No current browsers that I know of do this, but it still helps to be
correct.
