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?
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-250035572a c8},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-4ba79e6718 dc)]
interface nsIProcess : nsISupports
Looking at the xulrunner 1.9.0 "xpcom/ threads/ nsIProcess. idl" I found:
[scriptable, uuid(9da0b650- d07e-4617- a18a-250035572a c8)]
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.