Firefox Extension/Addon Binary Component Backward Compatibility - c++

Question

I have been reading up and looking at ways to compile binary components for Firefox extensions. Since Firefox 5 is being released (and 6 & 7 coming up soon) I was wondering if binary components are worth making anymore or just use a standalone executable to run the functionality I want.
I got a sample binary component to compile for Firefox 5 but when I tested it on Firefox 3.6, I get this error:
[Exception... "Could not convert Native argument arg 0 [nsISupports.QueryInterface]" nsresult: "0x8057000a (NS_ERROR_XPC_BAD_CONVERT_NATIVE)"
Running this code
var obj = Components.classes['#example.com/MyComponent;1'].QueryInterface(Components.interfaces.IMyComponent);
And errors at the QueryInterface. Apparently building for Firefox 4 (XULrunner-sdk 2.0 instead of 5.0 will work).
Here is the module code:
#include "mozilla/ModuleUtils.h"
#include "MyComponent.h"
NS_GENERIC_FACTORY_CONSTRUCTOR(MyComponent)
NS_DEFINE_NAMED_CID(MY_COMPONENT_CID);
static const mozilla::Module::CIDEntry kMyComponentCIDs[] = {
{ &kMY_COMPONENT_CID, false, NULL, MyComponentConstructor },
{ NULL }
};
static const mozilla::Module::ContractIDEntry kMyComponentContracts[] = {
{ MY_COMPONENT_CONTRACTID, &kMY_COMPONENT_CID },
{ NULL }
};
static const mozilla::Module kMyComponentModule = {
mozilla::Module::kVersion,
kMyComponentCIDs,
kMyComponentContracts,
NULL
};
NSMODULE_DEFN(NS_MyComponent_Module) = &kMyComponentModule;
NS_IMPL_MOZILLA192_NSGETMODULE(&kMyComponentModule)
I also heard that FF3.6 doesn't need to have the xpt or the dll inside the manifest file.
So basically my question is, for backward compatibility would it be better to make an executable or continue to make binary components? (Since it looks like compiling for FF5, FF3.6 broke.)

Answer 1

Your error message should be due to the XPT file not being recognized correctly (Components.interfaces.IMyComponent is undefined). Maybe that's because it is in the wrong directory - in Firefox 3.6 you don't declare it in the chrome.manifest file, instead it has to be located in the compoments/ directory along with your dll file.
The backwards compatibility story of XPCOM components got a lot worse starting with Firefox 4, see https://developer.mozilla.org/En/Developer_Guide/Interface_Compatibility#Binary_Interfaces. Theoretically, if you want to support multiple Firefox versions you need to put multiple versions of your XPCOM component into your XPI package, that's lots of effort for releases that come out every six weeks. If the point is really calling a few functions from a native library then you should seriously consider switching to js-ctypes. You can also ship a native library (plain, not XPCOM) with your extension and use js-ctypes to call it. Firefox supports js-ctypes starting with version 4 (Gecko 2.0), for Firefox 3.6 you would still need a different solution.