Re: NPAPI race conditions due to IPC

Benjamin Smedberg <[email protected]> Mon, 02 Mar 2015 10:40:35 -0500
Newsgroups gmane.comp.mozilla.devel.plugins
Message-ID <[email protected]>

On 3/2/2015 5:31 AM, [email protected] wrote:
> Hi,
>
>    I have a plugin which can create two types of scriptable objects and I can add one to another using JavaScript and id association in the plugin. I create one in HTML and the other one in JS. Example:
>
> HTML:
>    <embed id="a" type="application/x-a">
>
> JS:
>    b = document.createElement("embed");
>    renderer.setAttribute("type", "application/x-b");
>
>    a = documenet.getElementById("a");
>    a.add(b);
>
>
>    The problem which I am having is that NPN_Invoke for object a is called before NPP_New for object b. This is also visible in the invoke function because the _class member of the object which is given in the add function still has the default values.
>    If I call a function of b than the NPP_New function is called before NPN_Invoke.
>    The id association is done by trying to call a function of the object with NPN_Invoke:
>
> C++:
>
>    NPIdentifier identifier = NPN_GetStringIdentifier(GETID);
>    if (!NPN_Invoke(npp, object, identifier, 0, 0, &variant)) {
>      return 0;
>    }
>    obj = Manager.get(NPVARIANT_TO_INT32(variant);
>
>    The problem disappears when dom.ipc.plugins.enabled is set to false.
>
>
>    Could this be a problem caused by IPC? Is there a way to flush all the changes from javascript to the C++ code?

What release channel of Firefox are you using?

I don't understand your testcase exactly. You have two plugin instances 
of different types (x-a and x-b). Are those types rendered by the same 
plugin or different plugins?

The first (x-a) plugin is part of the document and should be 
instantiated when we parse the document.

You create an <embed> element for the second (x-b) plugin, but don't 
insert it into the document immediately. Then you call a method 
plugina.add(pluginbelement). We will not create a plugin instance for 
this element until it is part of the document, so it is expected that 
there will not be a plugin b instance for this element yet, and perhaps 
not ever unless you insert it into the document later on.

If you are using nightly or developer edition, it's possible that this 
symptom is related to a recent change in Firefox called asynchronous 
plugin instantiation, which causes plugins to be started asynchronously. 
But I really don't think that's the problem here.

--BDS

>
> Thanks in advance,
>
> Cosmin
> _______________________________________________
> dev-tech-plugins mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-plugins