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