Comment 13 for bug 359407

I believe I've found the problem. I was reviewing the two NS_ errors alongside reading up on the XPCOM programming book/tutorial.

Looking at the introduction to interface IIDs it reminded me of NS_NOINTERFACE found in comment #2.

I looked at the gdb debug log where I examined the aIID parameter:

8: aIID = (const nsIID &) @0x7fe6c50c2ca0: {m0 = 2644555344, m1 = 53374, m2 = 17943, m3 = "�\212%\0005W*�"}

I converted the first three parts (m0,m1,m2) to hex: 9DA0B650-D07E-4617-

Then I searched the source-code for the UUID.

In xulrunner-1.9.1 I could only find it in:

mozilla/testing/performance/win32/base_profile/xpti.dat:916:892,nsIProcess,{9da0b650-d07e-4617-a18a-250035572ac8},0,-1,1

I looked at the xulrunner 1.9.1 "xpcom/threads/nsIProcess.idl" and found nsIProcess has the IID "D573F1F3-FCDD-4DBE-...":

[scriptable, uuid(d573f1f3-fcdd-4dbe-980b-4ba79e6718dc)]
interface nsIProcess : nsISupports

Looking at the xulrunner 1.9.0 "xpcom/threads/nsIProcess.idl" I found:

[scriptable, uuid(9da0b650-d07e-4617-a18a-250035572ac8)]
interface nsIProcess : nsISupports

This matches the IID requested by IcedTeaPlugin, "9DA0B650-D07E-4617-*"

I looked at the differences in the interface descriptions of the two versions. It seems that apart from all the additional comments, the 1.9.1 interface has an additional member:

readonly attribute boolean isRunning;

Can an XPCOM expert confirm I've interpreted this information correctly?

If it is correct it has implications for the IcedTea/OpenJDK builds since to support both versions of xulrunner there would need to be two versions of the IcedTea Plugin built, one against the xulrunner 1.9.0 headers and the other against the 1.9.1 headers.

Would patching IcedTeaPlugin with additional code to detect the interface version at run-time and choosing the IID to pass based on that be sufficient to work around this issue, allowing one IcedTea/OpenJDK build to service both xulrunner versions?

This is something I'll investigate.