Firefox Plugins

 

 

    无论从任何角度看，讨论这个话题时，首先考虑到的参考还是应该是Mozilla的官方网站。虽然其不像MSDN，但是，就众多的开源项目而言，它的帮助文档已经算是比较正规的了，并且，量还是很大的。缺点是“量大而分类不足”，并且，“搜索不易”。在MDN上搜索WIKI，不如直接在GOOGLE中搜索。

 

    现在有个习惯，进入一个不熟悉的领域时，先找书。并且，平时也在积累各种各样的书，“书到用时方恨少”。看书也有很大的门道。凡书之开篇，都会是其主要灵魂的涉入点。凡事入门难，关键的就在前几章。当然，并不是说后面的不重要了。因为只有入得了门才能谈后继的发展。想起雪山飞狐中的胡斐练胡家刀法时，起初其没有得到胡家刀法的前几页，刀法总是练不上去，成不不大侠。后来得到那前几页刀法后，技法突飞。

 

    我把其WIKI上的文章按章节来区分（其本身并没有详尽的划分章节，而只是一系列的标题，如果我认为有的主题是可以放在一起的话我在此将其放于一处）。边看边划分。并以读书笔记的方式对其中个人认为挺重要的内容进行记录。

 

 

---

 

Chapter 1：前言

https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Preface

 

The Plug-in software development kit

A Plug-in software development kit (SDK) is available for Gecko plug-in developers. This SDK is located in the Mozilla source under modules/plugin/sdk/ . You can use it within the Mozilla source tree, or you can build it there and then use it outside of tree if you'd rather. In either case, the Mozilla source tree is required to get started developing plug-ins. You can also view the plug-in SDK samples and source code using the web-based source viewer: modules/plugin/sdk/

 

The SDK is based on the API developed originally for Netscape browsers starting with Netscape 2.x. Some additions were made when Netscape 3.x and Netscape 4.x were released. The present SDK reflects major changes related to Mozilla code base: LiveConnect for plug-in scriptability is no longer supported, existing plug-ins should be modified slightly to become scriptable again; the browser services are now accessible from the plug-in through the access to the service manager.

 

SDK在MOZILLA源码下的mozilla/modules/plugin/sdk/samples这个目录。这个目录进去后有一个MAKEFILE.in。也就是说如果编译一个xulrunner或者thunderbird，其也会生成Plugin的Sample。不过，它还是有对应vs工程文件的。这对于在vs中编译和调试还是方便些。

 

Scriptable plug-in

Yet another example of plug-in scriptability. The scriptable plug-in implements two native methods callable from the JavaScript, and it draws in a native window, so it uses different projects for the different major platforms.

 

对于入门而言，实例永远是一个重要的参考。它给出了一个有window的DEMO。draws in a native window ， 如果让自己来实现一个类似Flash的播放界面，我应该如何来画它的窗口呢！这是我之前一直在考虑的问题之一。不管怎样，这个DEMO一定不能错过了。

 

Chapter 2：Plugin基础

https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics

Plug-ins and Helper Applications

Before plug-ins, there were helper applications. A helper application is a separate, free-standing application that can be started from the browser. Like a plug-in, the browser starts a helper application when the browser encounters a MIME type that is mapped to it. Unlike a plug-in, a helper application runs separately from the browser in its own application space and does not interact with the browser or the web.

 

原来，在Plugin出现之前，对于现在的Plugin需求，是通过启用外部程序来实现的。在不能与浏览器紧密结合时，用这种办法来快捷使用。其实，这也是程序发展的一个过程。就像Adobe PDF Reader。其实，它本来就是单独的一个软件，是有了这个软件后才有的Reader插件。这种情况下对FLASH是不利的，HTML中放置众多.swf要是都只能在浏览器外显示，对整个的UE确实是一个沉重的打击。

 

Understanding the Runtime Model

Gecko calls the plug-in API function NP_Initialize when the plug-in code is first loaded. By convention, all of the plug-in specific functions have the prefix "NPP", and all of the browser-specific functions have the prefix "NPN"

 

当Plug-in首次加载时，其调用Plugin中的NP_Initialize函数。这似乎是一个与NPP命名规范冲突的地方。

How Gecko Finds Plug-ins

On Windows, installed plug-ins are automatically configured to handle the MIME types that they support. If multiple plug-ins handle the same MIME type, the first plug-in registered handles the MIME type.

 

如果有多个Plugin注册的同一个MIME类型，那么将用第一个注册的来处理该MIME。

 

Understanding the Plug-in API

A plug-in is a native code library whose source conforms to standard C syntax. The Plug-in Application Programming Interface (API) is made up of two groups of functions and a set of shared data structures.

 

写Plugin时还是用C的语法吧！不要和C++混了。

 

Registering Plug-ins

Gecko identifies a plug-in by the MIME type it supports. When it needs to display data of a particular MIME type, the browser finds and invokes the plug-in object that supports that type. The data can come from either an object element in an HTML file (where the object or embed element either specifies the MIME type directly or references a file of that type), from a separate non-HTML file of that MIME type, or from the server.

The server looks for the MIME type registered by a plug-in, based on the file extension, and starts sending the file to the browser. The browser looks up the media type, and if it finds a plug-in registered to that type, loads the plug-in software.

 

这一段差点没看晕了......

 

A MIME type is made up of a major type (such as application or image) and a minor type, for example, image/jpeg . If you define a new MIME type for a plug-in, you must register it with IETF (Internet Engineering Task Force ). Until your new MIME type is registered, preface its name with "x-"。

 

MIME其实最开始是在邮件中传附件时用的，而MIME最终在HTTP中传文件用的非常多。自定义邮件头和自定义MIME类型都以x-开头

 

The Windows version information for the plug-in DLL determines the MIME types, file extensions, file open template, plug-in name, and description. In the MIME types and file extensions strings, multiple types and extensions are separated by the "|" character, for example:

   video/quicktime|audio/aiff|image/jpeg

For the browser to recognize the plug-in, the version stamp of the plug-in DLL must contain the following lines:

• File Extents: for file extensions
• MIME Type: for MIME types
• Language: for language in use

在Visual Studio中编译Plugin的DLL时，需要加入添加资源”Version“。

从实际来看，MIMEType是无论如何也要加的。

 

In your development environment, make sure your language is set to "US English" and the character set to "Windows Multilingual." The resource code for this language and character set combination is 040904E4.

 

这句话又看的有点晕了。。。。。。

 

Plug-in Installation and the Windows Registry

An important aspect of the installation process on the Windows platform is the reading of registry keys to determine how many Gecko-based browsers are installed locally, which they are, and how they are configured for plug-ins.

Whether you are using a native Windows installer like InstallShield or writing installation scripts using the The XPInstall API (see "XPI Plug-ins Installations" ), you can access the registry, read and write data about your plug-in, and customize your installation for the different Gecko installation targets, as this section describes.

The registry keys that affect the installation of plug-ins are subkeys of the various Gecko-based products enumerated under:

HKEY_LOCAL_MACHINE/Software/Mozilla

The products are listed as subkeys of the Mozilla key. You can enumerate these subkeys to get the Gecko-based browsers, and further enumerate those subkeys to read such important configuration information as where in the browser application directories the plug-in should be installed, which version is installed, and so on.
The Plugins key-value pair shows where plug-ins should be installed for that Gecko-based product:

Plugins = C:/Program Files/Mozilla Firefox/plugins

For all but the newest Gecko-based products, the Components key-value pair also holds an important piece of information: As described in the "Type Libraries" section above, Gecko-based products require that you put the type library file, or XPT, in the Components subdirectory.

Components = C:/Program Files/Mozilla Firefox/components

Also, the product subkey (e.g., Mozilla/Mozilla Firefox 2.0.0.1) has a bin subkey which exposes the PathToExe key-value pair:

PathToExe = C:/Program Files/Mozilla Firefox/firefox.exe

See the XPInstall registry manipulation example for more information about how these key values from the registry can be used to steer your installation for different targets.

 

这几个注册表项在最新的FIREFOX安装后才有。之前的1.0版本是没有的。Firefox 3.6版本是肯定有这些注册表项的。而在事实上，应该可以通过注册表告诉任何一个Gecko的application在哪里可以找到我装的插件。所有的GECKO都能在同一个地方找到可以用的插件。具体是怎样写这个注册表项还得再看一下。好像目前没看到哪里写了。可以肯定的是这是一定能做到的。

 

Chapter 3：Plug-in API

1.NP_Initialize

2.NPP_New

3.NPP_Destroy

4.NP_Shutdown

 

This chapter describes the methods that provide the basic processes of initialization, instance creation and destruction, and shutdown.

• Initialization : The browser calls the Plug-in API function NP_Initialize when the plug-in code is first loaded.
• Instance Creation : The browser calls the Plug-in API function NPP_New when the instance is created.
• Instance Destruction : The plug-in instance is deleted when the user leaves the instance page or closes the instance window; the browser calls the function NPP_Destroy to tell the plug-in that the instance is being deleted.
• Shutdown : When the last instance of a plug-in is deleted, the plug-in code is unloaded from memory and the browser calls the function NP_Shutdown . Plug-ins consume no resources, other than disk space, if not referenced.

Initialization

The browser calls NP_Initialize when a plug-in is loaded and before the first instance is created. Use this function to allocate the memory and resources shared by all instances of your plug-in.

NPError NP_Initialize(void) {

};


After  the last plug-in instance is deleted, the browser calls NP_Shutdown , which releases the memory or resources allocated by NP_Initialize .

 

In the initialization process, the browser passes the plug-in two tables of function pointers for all API calls:

• One table lists all API calls from the plug-in to the browser. This table is filled out by the browser before the initialization call.
• The other table lists all API calls from the browser to the plug-in. This table is filled out by the plug-in during the initialization call.

The function tables also contain version information that the plug-in checks to verify that it is compatible with the API capabilities provided by the application. To check this information, use NPN_Version .

 

No plug-in API calls can take place in either direction until the initialization completes successfully, with the exception of the functions NP_Initialize and NP_Shutdown , which are not in the function tables. However, because NP_Initialize is called at the end of the initialization process, you can call other methods, such as such as NPN_MemAlloc and NPN_Status , from NP_Initialize .

 

在初始化完成之前，插件与浏览器之间不能相互调用任何函数。当然，除NP_Initialize和NP_Shutdow之外。而NP_Initialize是在初始化进程的最后，因此，在这个函数中可以调用其它的函数。

 

Instance Creation

After initialization, the plug-in instance is created. More than one instance of the same plug-in can exist if a single page contains multiple embedded plug-ins, or if several browser windows are open and display the same data type. At this point, a plug-in can call the NPN_SetValue function to specify whether it is windowed (the default) or windowless.

 

居然是在这个地方调用NPN_SetValue来指定是windowed还是windowless类型的插件

 

NPError NPP_New(NPMIMEType pluginType,

NPP instance, uint16 mode,

int16 argc, char *argn[],char *argv[],

NPSavedData *saved);

The mode parameter identifies the display mode in which the plug-in was invoked, either NP_EMBED or NP_FULL .

    * NP_EMBED means that the instance was created by an EMBED and shares the browser window with other content.
    * NP_FULL means that the instance was created by a separate file and is the primary content in the window.

mode用来指定Plugin是用于嵌在HTML网页中还是在一个单独的页面中。之前文章讲过的显示插件的代码好像又忘记了。不过，就它的显示方

式来看，一个单独显示在浏览器中的.pdf文件就是这里这种形式。


The next three parameters pass parameters from the embed element that called the plug-in. The argc parameter is the

number of HTML arguments in the element. It determines the number of attributes in  the arrays specified by the argn

and argv parameters.


接下来的三个参数是从<embed>中传入的。argc是<embed>属性的个数，argn  argv是对应的attribute name 和attribute value。

Drawing and Event Handling

When it comes to determining the way a plug-in instance appears in a web page, you (and the web page author) have many options. The content provider who writes the web page determines its display mode : whether the plug-in is embedded, or displayed in its own separate page. You determine whether a plug-in is windowed or windowless by the way you define the plug-in itself.

• A windowed plug-in is drawn into its own native window (or portion of a native window) on a web page. A windowed plug-in is opaque, hiding the part of the page beneath its display window. This type of plug-in determines when it draws itself.
• A windowless plug-in does not require a native window. It is drawn in a target called a drawable , which corresponds to either the browser window or an off-screen bitmap. A drawable can be defined in several ways, depending on the platform. Windowless plug-ins can be opaque or transparent. A windowless plug-in draws itself only in response to a paint message from the browser.

Plugin是嵌在HTML页面中还是显示在一个单独的窗口里这由WEB开发人员来定，而Plugin是有窗口的还是无窗口的是写插件时就定下了的。