问题
I am currently learning how to create Firefox addons using XPCOM and I want to know how to include thirdparty libraries to develop them. I followed a few tutorials to compile .xpt and .dll from c++ files (noted in: https://developer.mozilla.org/en/How_to_build_a_binary_XPCOM_component_using_Visual_Studio and http://nerdlife.net/building-a-c-xpcom-component-in-windows/) and I am not sure how we are suppose to include the files into an addon project (which gets packaged into .xpi file).
I am using Opencv (c++) to do image conversions via the addon such as resizing a very large image (3mb high res png) down to something small and simple (such as 600X800 200kb jpg) that will be done by my addon. I know that Opencv is written in c++ and xpcom can compile c++ code into a dll and xpt. I read a couple of tutorials but most of them points to adding these files (xpt and dll) in "C:/Program Files(x86)/Mozilla Firefox/components" instead of the addons "components/" folder (which is not how addons work, I believe). Though the Mozilla page (listed above) does include something about "{app}/components" and "{app}/application.ini" folders but I have never read anything like this, so therefore I am confused how this is done.
My other option is making the Opencv methods into an executable and then running it separately (similar to how MemoryFox addon runs an executable to clear Firefox's memory) and use that to conduct image resizing.
I am really not sure how to do this (I am new the addon development) and I would like to know how to accomplish this (using 3rd party C++ libs into the addons). An example, tutorial or explanation is fine to get me started.
Thanks in advance.
Edit: I would also like to inform that I have read threw most of https://developer.mozilla.org/en/Creating_XPCOM_Components (picked and choose topics) and it does not tell me how to achieve the above.
回答1:
The tutorial you refer to is about developing applications, not extensions. So application.ini doesn't apply in your case. Extensions have a manifest file called chrome.manifest, starting with Firefox 4 all XPCOM components and XPT files need to be registered there - or they will be ignored. It no longer matters where the component is located though components/ would still be the common place for them. https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Component_registration should be a good starting point - that should explain what you need to write there.
Note that the source code in the tutorials you were reading is outdated as well. Current code examples are linked to from https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Binary_components. And you should use XULRunner SDK 2.0 (corresponds to Firefox 4) or higher. Sorry, you arrived at a bad time - that's the biggest change to XPCOM in the past 10 years.
回答2:
There are several places you can store an addon and inform FireFox of it's existence. Mostly it comes down to how you want to distribute it.
With MS Windows the loadLibrary process will search the current directory then the path. Simply locating your xpcom.dll alongside 3rdparty.dll in the components folder of your pluggin should work ok.
XPCOM is like windows COM but for across platforms.
Your designing to meet the requirements of interfaces.
Your addon may not need to define it's own interface (.idl -compiles-> .xpt, .h) but if it does from firefox 4 you will need to list this in the chrome.manifest.
Once compiled you will need to list your dll in the chrome.manifest also.
taking your example prototype function
long Add(in long a, in long b);
baz_1.idl might look like
#include "nsISupports.idl"
[scriptable, uuid(F0F0F0F0-AAAA-BBBB-CCCC-111111111111)]
interface iBaz : nsISupports
{
long Add(in long a, in long b);
};
generate your header and xpi distrib
$(GECKOBIN_PATH)/xpidl -m header -I $(GECKOSDK_PATH)/idl -e baz_1.idl
$(GECKOBIN_PATH)/xpidl -m typelib -I $(GECKOSDK_PATH)/idl -e baz_1.idl
Link the contract guid to the contract name in C++ for FF4
NS_DEFINE_NAMED_CID(BAZ_CID); // defined in baz.h generated from baz_1.idl
static const mozilla::Module::ContractIDEntry kSLMozContracts[] = {
{ "@foo.bar.com/baz;1", &kBAZ_CID },
{ NULL }
};
usage in C++nsCOMPtr<iBaz> baz = do_CreateInstance("@foo.bar.com/baz;1",&rv);
usage in JavaScriptvar baz = components.classes["@foo.bar.com/baz"] .createInstance(Components.interfaces.iBaz);
Example.
We have a product that also provides a firefox addon, so we don't ship an xpi, but the addon sits in a subfolder of the product.
Product inc:\program files\foo\
addon in - lets call this foobarc:\program files\foo\bar
register the addon
HKLM\SOFTWARE\Mozilla\Firefox\Extensions\
"{GUID}"="c:\program files\foo\bar"
so then the layout of the addon is
foobar\chrome.manifest
foobar\install.rdf
foobar\components\baz_1.xpt
foobar\components\baz_1_32.dll
foobar\components\baz_1_64.dll
foobar\components\someOtherWorker.dll
foobar\chrome\ui.jar
In FF < 4 you didn't need to list binaries in the manifest, things in components folder are loaded and checked for functions to see if they are xpcom, so a chrome manifest might have looked like
content baz jar:chrome/ui.jar!/content/baz/
skin baz classic/1.0 jar:chrome/ui.jar!/skin/classic/baz/
From FF 4 the chrome manifest needs to list your binary files, so it then looks like (we only support 64 bit after FF 3.5)
content baz jar:chrome/ui.jar!/content/baz/
skin baz classic/1.0 jar:chrome/ui.jar!/skin/classic/baz/
interfaces components/baz_1.xpt
binary-component components/baz_1_32.dll ABI=WINNT_x86-msvc
binary-component components/baz_1_64.dll ABI=WINNT_x86_64-msvc appversion>=3.5
FireFox 5 (Out now) has changed
- the formats of xpt files - so your interfaces won't be found by FF5 unless you build with that SDK.
- the version of the xpcom registration - so FF5 won't use a dll built for FF4 as the xpcom version isn't high enough.
来源：https://stackoverflow.com/questions/6474698/how-does-someone-use-thirdparty-libraries-to-be-included-in-firefox-addons-exten