NPAPI race conditions due to IPC

[szanto...@gmail.com]

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?

Thanks in advance,

Cosmin

[Benjamin Smedberg]

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
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-plugins

[szanto...@gmail.com]

Sorry for not making my self clear.
Yes, I have two plugin instances of different types which are created by the same plugin.

The created <embed> element is added to the document before it is added to the plugin.

I am using Firefox 36, for Fedora 20.

[Benjamin Smedberg]

Could you file a bug with a minimal testcase, then? With a small plugin
along with HTML code that exhibits the problem, we'd probably solve your
problem faster than trying to debug it over a newsgroup. NEEDINFO me
after you've filed the bug.

I still have a feeling that this is somehow related to the order that
you insert the plugin element into the document; that we don't
necessarily instantiate plugins the instant they are inserted, and that
may be throwing off the rest of the testcase.

--BDS

[ric...@batemansr.us]

Across multiple browsers the startup order you're using has long been unreliable; you can't be guaranteed that the plugin will be instantiated the line after you insert it into the DOM. There are a couple of ways I've seen this solved:

1) Do a setTimeout to give the browser a little time to load it up; you could even poll until your method is available to see if it's started up yet

2) My preferred way is to add a param tag with the name of a global javascript function to call once the plugin is loaded. In your plugin once it has loaded just call that method, optionally giving it the NPObject as a parameter. This is my preferred method; you can even set a timeout so that if the plugin doesn't load you can decide to do something about it.

Even if the good folks at Mozilla fix the testcase for you (and I'm not convinced this is a "bug" as such) it won't fix Safari or Opera; Chrome of course is dropping NPAPI support next month.

- Richard
FireBreath.org

[szanto...@gmail.com]

On Monday, March 2, 2015 at 12:31:34 PM UTC+2, szanto...@gmail.com wrote:

I've filed a bug and attached a test. https://bugzilla.mozilla.org/show_bug.cgi?id=1139434