Windows下的Firefox plugins开发的N个坑

首先抱怨一下，Firefox插件开发实在是缺乏必要的文档，就连硕果仅存的几个sample code也存在没有文档化的坑，需要我花一番心思才能完全搞定。OK，为了方便后来者，我在这里把现在踩过的坑列举一下。

注：下面的内容仅针对plugins开发，对extension开发没有任何意义。

1. 编译出来的dll一定要以np开头

这是我遇到的最变态的问题。我还记得有一天辛辛苦苦写了半天代码，编译运行后发现firefox竟然死都识别不了我的插件，后来回滚代码无数次依然不行，让我极其郁闷。后来几乎重写所有代码才回到正轨。

再后来，我偶然发现dll改了名就会不识别，只有np打头的dll才能被识别，这才让一切都明了。这实在是plugins编程中最变态的坑，至今我也没在任何官方文档中发现对这个特性的说明。

2. 插件dll的VERSIONINFO的代码页一定是英文（0x0409）

如果不是，那么插件100%不能被正常识别。我就是一开始不小心把这个搞成了中文（936），结果怎么都注册不了。

同时还要注意整个资源的代码页也一定要是英文，否则一样问题。

3. NP_GetEntryPoints居然没有正式的文档

这个函数是plugins里面最重要的一个函数，浏览器和插件交互就全靠它了，但可惜的是根本没有官方的文档介绍它，包括入口参数、返回值还有一些可能需要注意的地方都只能看sample code自己揣摩，有没有搞错。

个人觉得这事情非常不靠谱。

4. xpt文件一定要放到firefox安装目录的modules目录下

虽然MDC的文档明明说在注册表里指定xpt路径就好，但这种方法不工作，根本原因是这东西从来就没有真正实现过。

P.S. 我知道xpt这种东西在plugins开发中已经被淘汰，但是最新的Gecko SDK 1.9的例子全部用的是idl/xpt方式实现，我偷了个懒用了SDK中的例子，但没想到就遇到了这个坑。既然NPRUNTIME从Firefox 1.5开始已经是plugins开发的正宗，为什至今为止还没有任何完全用NPRUNTIME开发的插件示例，这实在不像话。

5. 最好不要把ns*String类和NS_*LITERAL_STRING、NS_Convert*混用

nsAString、nsString、nsAutoString以及一系列string相关的变种是firefox里少见的好用的类，不过也有一些的坑，且最好不要使用。

按照MDC的文档，这些string类经常和NS_*LITERAL_STRING、NS_Convert*混用，例如NS_LITERAL_STRING和NS_ConvertUTF8toUTF16。一旦这样用了，程序就必须同时链接xpcomglue.lib和xpcom.lib，可是MDC的文档又在编译说明的Note里面明令禁止这两个lib一起链接（没说理由，我也还没找到切实的原因），因此，为了在写插件的时候不发生什么意外的人品问题，还是不要混用的好。

令人感到尴尬的是，如果不混用这些东西那么ns*String也就完全没有使用的必要了。

首先，ns*String不能与普通字符串相加，下面的代码是非法的：

nsAutoString str;
str = str + "test";

这个"test"必须用NS_LITERAL_STRING()包装成nsAString才能参与运算，如果不能使用这个宏那该多痛苦。

其次，失去NS_Convert*函数帮忙之后，ns*String与STL相比没有任何优势，用起来还麻烦，不如直接用STL的string。

最后，ns*String也不能用来给js传值。属性的Get方法传递参数时必须用NPN_MemAlloc()申请新的空间，这个函数实际上调用了plugins初始化时得到的NPNetscapeFuncs::memalloc()函数指针。ns*String并没有调用这个函数，所以里面的空间总是会在传递到js之前就被释放，使得js始终得到一个空字符串（默认的返回）。不能用来传值那为什么还要使用它？很少有属性是被设计成只写的吧。

其实正宗的plugins开发应该用NPString，的确不应该再使用ns*String了。所以更好的建议是：不要在plugins里面继续使用ns*String了。

6. 做好心理准备，VS2008的link可能会崩溃

不知道是什么原因，在我这里VS2008的link经常会在编译plugins的时候崩溃，这实在很影响效率。也许这是个例，我用的操作系统是Win7 RC。

规避的方法是每次都完全重新编译，不要使用增量编译。

原文地址：http://hi.baidu.com/realdodo/item/f17fe20670445e12cc34ea94