Source code analysis and Installation Process Analysis of Mozilla Firefox extension insider tutorial (XPInstall, XPCOM, RDF, xpi, chrome, manifest)

ArticleDirectory

• 2.1 extensions)
• 2.2 chrome
• 2.3 xulrunner
• 2.4 XPCOM
• 2.5 XP install
• 3.1 Firefox extension Structure
• 3.2 extended Installation Process
• 3.3 Analysis of the XP install Module
• 3.4 analysis of the rdf Module
• 3.5 extended Startup Process
• 4.1 difficulties in Analysis
• 4.2 analysis gains

I am too lazy to organize the following figure. Upload a PDF file directly. If you are interested, check it out. In fact, it's just a job. You can store it as your knowledge. Http://files.cnblogs.com/kenkofox/firefoxextended related code analysis report (kenko).pdf I. Analysis task description

The content of this report is for FirefoxSource codeRelated to its extensionsCodeThe architecture of extensions is summarized and analyzed as much as possible.

This report details the Firefox extension structure and related code relationships in section 3.

 

Ii. Knowledge about Firefox extensions 2.1 extensions)

Extensions adds new features to Mozilla Firefox. Extensions allows you to add a toolbar button or implement a complete new function. Extensions makes Firefox more suitable for individual needs.

Extensions is different from plugins. The plug-in helps the Browser display special content, such as playing a multimedia file. A common plug-in is Flash Player. Extensions is different from the search engine plug-in. The search engine plug-in only adds an additional search engine address in the search bar.

An extension is usually an xpi (cross-platform installer module) package. It is actually a zip package containing necessary files. Figure 1 below shows the directory structure of a standard extension including files and files.

Figure1FirefoxExtended directory structure 

InFigure 1Under the content directory, the XUL file of the extended description interface and the Javascript file that adds behavior are stored. The Locale directory stores local files. To support both English and Chinese, you can create the en-US and ZH-CN directories under the locale directory to store the corresponding localized strings. The skin directory stores some CSS files to define the extended appearance. Chrome. manifest is a configuration file registered by chrome (see section 2.2 ). Install. RDF contains the extended installation information.

2.2 chrome

Chrome refers to applications.ProgramA set of user interface elements outside the content area of a window. These user interface elements include toolbar, menu, progress bar, and window title bar. The chrome provider can provide chrome for specific window types (such as browser windows. There are three basic chrome providers:

L content: Usually an XML user interface language (XUL) file. The XUL file will specify the interface and functions for extending the runtime performance in Firefox. XUL is a Javascript file designed to describe the content of the window and dialog box.

L region (locale): stores localization information.

L skin (skin): Describes the appearance of chrome. It usually contains CSS and image files.

2.3 xulrunner

The xulrunner project provides a set of Mozilla running support packages called xulrunner To Start Programs Based on XUL + XPCOM (see section 2.4), such as Firefox, Thunderbird, and sunbird. It provides various mechanisms, including installation, upgrade, and removal of these software features.

The main interface and Extended Interface of Firefox are described by XUL files. Therefore, xulrunner is used to support both the main interface and Extended Interface of Firefox.

2.4 XPCOM

XPCOM(Cross Platform Component Object Model) is a cross-platform component object model, similar to Microsoft's com. It has a variety of language binding, so that the XPCOM component can be used and implemented in C ++, JavaScript, Java and python. The interface of XPCOM is defined by Interface Definition Language.

XPCOM itself provides a set of core components and categories, such as file and memory management, threads, and basic data structures (strings, arrays, variants. Most XPCOM components are not provided by core components, but by other platforms or applications, or even extended suites.

In Firefox, most of the functions are based on the XPCOM mechanism. For example, all interfaces provided by Firefox for extension development are implemented using the XPCOM method.

For example, GRDF = components. classes ["@ mozilla.org/rdf/rdf-service1_1"]

. Getservice (components. Interfaces. nsIRDFService );

The nsIRDFService instance of the RDF module is obtained.

2.5 XP install

XP install (cross-platform install) is a technology used to install extensions in Mozilla software or other XUL-based software. In the source code of firefox2.0, there is a folder named XPInstall, which stores the Code related to the XPInstall module.

In addition, it should be noted that Firefox extensions are dividedGeneral default extension and custom installation Extension. General default extensions do not have custom installation code. The entire installation process is executed by the Firefox default process. The customized installation extension installation package contains the customized installation process information. This information is written in specialized JavaScript code and is implemented by calling the API provided by XPInstall. A common example is to use Firefox to open the extension center. You can click an extension to install it online. In this example, the XP install API is called.

Iii. source code analysis result 3.1 Firefox extension Structure

Figure2FirefoxExtended Structure Diagram

 

 

Figure 2Shows the structure of Extended parts in Firefox. Among them, necko is the core part of Firefox's processing network, while gecko is the core of Firefox's webpage explanation, or the kernel, that is, layout engine. The RDF module implements a series of XPCOM interfaces to read the information of the RDF file during the installation or processing of the extension.

During the extended installation process, the main responsibility of the XP install is: if the XP install finds that the extension is a common default extension, it will be handled by the relevant part of the extended installation in the Toolkit Module (not shown in the figure.

Extended running requires support from the chrome registration module. When Firefox is running, the extended chrome information is registered to the registration module, and then presented to xulrunner for display. All the features provided by the kernel involve XPCOM. All Firefox interfaces are implemented by xulrunner. So,During the expansion operationFirefoxIntegrationExtended interaction with the Firefox kernel, and the interaction with the Firefox main interface and the kernel. The two types of interaction are the same. Both are on the xulrunner platform, and XPCOM is called to implement the corresponding functions.

3.2 extended Installation Process

The Installation Process of the extended summary is as follows:Figure 3As shown in:

Install events intercepted by Firefox

Checks the RDF installation information.

Extract installation code

Run the installation code

Figure3 Overview of the extended Installation Process

XPInstall detection Extension

Decompress xpi and save it to the corresponding folder (create or replace the original file)

Complete installation

Common default Extension

Custom installation Extension

Suitable Installation

Not suitable for Installation

The extension installation is mainly undertaken by the XP install module, and the top entry for processing the extension installation in the XP install module is nssoftwareupdaterun. cpp. This file defines the runinstall () function. The main program of Firefox can set parameters so that runinstall () is a single thread or multiple threads call runinstallonthread () for installation.

Figure4XP installInitial installation process

Figure 4It is the key process to start the installation and expansion of the XP install. The nssoftwareupdate class contains several installation-related operations, while nsizipreader is an XPCOM interface with an interface for reading the xpi package. The installinfo class encapsulates the key information of the extension currently installed, the final nsextensionmanager is also an XPCOM interface, which is implemented by the code in the extension part of the Toolkit Module, specifically for general default extensions.

In the above process, there are two key steps: openandvalidatearchive () to verify that the current xpi complies with the specifications, and digital signature security. In addition, test ("Install. RDF") determines whether the current xpi belongs to a common type. If install. RDF exists, the current extension is treated as a common extension. Then, call nsextensionmanager for the next installation.

Next, we will focus on the installation process in nsextensionmanager. For exampleFigure 5As shown in:

 

Figure5NsextensionmanagerInstallation Process

In nsextensionmanager, use components. classes ["@ mozilla.org/rdf/rdf-service1_1"]. getservice (components. Interfaces. nsIRDFService) to obtain the nsIRDFService service. Call getinstallmanifest () to obtain the installation information from install. RDF. DS is saved to the global variable _ metadatads.

Call the getresource () of nsIRDFService to extract the installation information, such as maxversion and the unique identifier guid of the extension, and check whether it is suitable for installation.

After obtaining the installation location through getinstalllocation, call the install class function installfromfile () to complete the installation. Specifically, _ installextensionfiles () and safeinstalloperation () are called to deploy the target folder (Window XP is C: \ Documents and Settings \ USERNAME \ Application Data \ Mozilla \ Firefox \ profiles \ profile \ extensions), decompress all xpi files and place them in the specified location. Among them, safeinstalloperation () ensures that if an error occurs during file copying, it can be fully rolled back.

Nsextensionmanager finally calls _ updateextensionmanifest () to update the extension information table and adds the new extension file information to the Summary table for the Toolkit to read when Firefox starts. For details, see section 3.5.

If install. RDF is not available, XPInstall will callFigure 6. The most important one is initxpinstallobjects (). This call will call almost the entire XP install class in nsjsinstall. Since this analysis mainly focuses on common default extensions, we will not go into the specific process of the XP install. For the structure of the XP install, see Section 3.3.

 

Figure6 Customized extension Installation Process

3.3 Analysis of the XP install Module

Table1XP installMain Category

Class Name	Function Description
Nsinstall	Implement most external APIs of the XP install (For details, refer to the API description of the XP install, Which is omitted in this report ), Record the information of the current installation package in the class
Nsinstalluninstall	Record an extension to be deleted
Nsisoftwareupdate	Update the public interfaces used by extensions or plug-ins in XP install, such as installchrome ()
Nssoftwareupdate	Nsisoftwareupdate
Nsxpinstallmanager	Manage the list of extensions to be installed and provide peripheral functions, such as downloading extensions and completing installation.
Nsinstallfolder	Directory object used during installation
Nsinstallfile	File objects used during installation
Nsinstallinfo	Record the details of the extensions currently installed, and have important functions Getextensionmanager (). This function returns the entity of the nsiextensionmanager interface, which is used to install the default extension (as described in the previous chapter.
Nsxpitrigger	Start of control extension Installation For example, allowinstall (), installchrome (), and other functions
Ninstallversion	Extended version to implement functions such as comparison before and after
Nsinstallobject	Basic base class
Nswinprofile	Reads and writes files such as extensions. ini.
Nsinstallresources	Auxiliary Functions for reading resources

 

The main class diagram of XPInstall is shown in figureFigure 7.

 

Figure7XP installMain class structure diagram

3.4 analysis of the rdf Module

Table2RDFMain modules and interfaces

Class Name	Function Description	Corresponding Interface
Rdfserviceimpl	The core of the entire RDF module. Implement most external interfaces. In particular, getdatasource ()	NsIRDFService
Rdfcontentsinkimpl	Classes that store the RDF content, and have corresponding operations and helper functions for the content For example, getresourceattribute ()	Nsirdfcontentsink
Rdfxmlperformanceimpl	Operations on XML-type RDF files	Nsirdfxmlsource Nsirdfdatasource
Nsdfxmlparser	A helper class used to interpret XML files	Nsirdfxmlparser
Rdfcontainerutilsimpl	Create rdfcontainer class	Nsirdfcontainerutils
Rdfcontainerimpl	Manage data sources	Nsirdfcontainer
Rdfutil	Simple helper class for string operations
Nsdfxmlserializer	Used to serialize RDF	Nsirdfxmlserializer

 

 

 

The relationship between the main classes and interfaces of the RDF module is as follows:Figure 8.

 

Figure8RDFRelationship between main modules and interfaces

 

3.5 extended Startup Process

Toolkit obtains the content of extensions. ini.

Nschromeregistry processes manifest files for each extension

Nsxuldocument

Start xulrunner

Figure9 Extended Startup Process

 

 

 

The Startup Process of the extension is as follows:Figure 9As shown in:

1. The nsxredirprovider of Toolkit reads extensions. ini and extracts the chrome. manifest file for each extension.
2. Nschromeregistry implements nsixuloverlayprovider and nsitoolkitchromeregistry interfaces. Processmanifestbuffer () processes all manifest files and then adds the corresponding content to the corresponding container. For example, overlay XUL objects are added to moverlayhash. These containers are static.
3. The nsxuldocument of the xul component calls nsixuloverlayprovider's getxuloverlays () to obtain the extended XUL list and add the extended XUL to the main model.
4. Xulrunner starts Firefox Based on the XUL file.

 

Iv. Summary and experience 4.1 difficulties in Analysis

1. In the process of analyzing Firefox source code, the biggest problem encountered is that the expansion involves too wide scope. Although many documents are supported, there is no ready-made support for directly analyzing the corresponding code. I had to change the direction after I first planned to study Firefox's support for extended APIs and gradually learned about the extended mechanism. Because there are too many source code involved in the extension, and Firefox, apart from the kernel, is based on XUL and XPCOM. This architecture makes expansion very simple, but it is very difficult for us to study. For example, XUL is a sub-project of Firefox. It is a big task to analyze this part independently.
2. The source code of Firefox is very large, and it is a great job to find out which code is related to expansion.
3. The tool for analyzing code is insufficient. For example, Firefox extension involves three types of code: C ++ code, IDL code, and JavaScript code. C ++ code has a good editor to read, but it is still not enough, because it is very difficult to study the function call sequence, because the source program is not compiled and there is no code navigation function. While IDL and JavaScript are even more difficult to read. During the study, we had to use Ctrl + F for constant search.
4. For most of the students in the group, it was the first time that they formally studied a certain part of the software code. This process often tells us how to find out what we need in the source code of the software.
5. Of course, the biggest achievement of this process is to lay a good foundation for our development and expansion, so that we can understand the extended structure and working mechanism from the outside to the inside. This makes it easier to understand and get started with the XUL and RDF compiling specifications during development. This is also the biggest purpose of our research to expand the relevant code.

4.2 gains from analysis 5. Work prospects

In this study, due to limited time and ability, the breadth and depth of the study are still quite inadequate. In the future, we will gradually conduct in-depth research on Firefox source code around the extension. For example, the first research direction is the specific structure of xpcom and the xulrunner part.