XPCOM

XPCOM is a cross platform component object model, similar to Microsoft COM. It has multiple language bindings, allowing XPCOM components to be used and implemented in JavaScript, Java, and Python in addition to C++. Interfaces in XPCOM are defined in a dialect of IDL called XPIDL.

WebExtensions are becoming the new standard for creating add-ons. Eventually support for XPCOM add-ons will be deprecated, so you should begin to investigate porting your add-ons to use the WebExtensions API, and report any missing functionality so we can be sure to address your concerns. Work is ongoing on WebExtension capabilities, so your input will help prioritize and plan the work. To learn more about the kinds of changes that will be needed, see Comparison with XUL/XPCOM extensions. In addition, any binaries you use will then need to be converted for use with the WebExtensions native messaging API, or compiled using WebAssembly or Emscripten.

XPCOM itself provides a set of core components and classes, e.g. file and memory management, threads, basic data structures (strings, arrays, variants), etc. The majority of XPCOM components are not part of this core set and are provided by other parts of the platform (e.g. Gecko or Necko) or by an application or even by an extension.

Accessing the Windows Registry Using XPCOM: When implementing Windows-specific functionality, it is often useful to access the Windows registry for information about the environment or other installed programs. To this end, there exist XPCOM interfaces to read and write registry data. This article will show you how to use the available interfaces in several Mozilla products.
Aggregating the In-Memory Datasource
Binary compatibility: If Mozilla decides to upgrade to a compiler that does not have the same ABI as the current version, any built component may fail. It is a possiblity that is introduced when upgrading to a new compiler without recompiling everything. Effectively, it is a different platform.
Bundling multiple binary components: Binary XPCOM components are sometimes required to implement low-level features for extensions. Since binary components are linked against a single Gecko SDK, a dependency to a particular version of Gecko is created. If the component uses only "frozen" XPCOM interfaces, there is a good chance the same binary component will work with different versions of Gecko (version 1.8 and 1.9, for example). The more likely case is that the component uses "unfrozen" interfaces and those interfaces can change between Gecko versions. This can create a difficult situation for extension developers trying to support multiple Gecko versions (Firefox 2 and 3, for example).
Creating a Python XPCOM component: Creating Applications with Mozilla already provides a tutorial for making a simple JavaScript or C++ component (implementing the nsISimple interface). Here is how to make the same component in Python using PyXPCOM.
Fun With XBL and XPConnect
Generating GUIDs: GUIDs are used in Mozilla programming for identifying several types of entities, including XPCOM Interfaces (this type of GUIDs is callled IID), components (CID), and legacy add-ons—like extensions and themes—that were created prior to Firefox 1.5. Add-ons can (and should) be identified with IDs of the form extensionname@organization.tld since Firefox 1.5.
Generic factory: Most XPCOM factories can be very simple. Rick Potts wrote a templated-based generic factory (nsFactory<t>) that simplifies the factory creation process that just requires writing a CreateInstance() method. The new nsIGenericFactory interface takes this a step further, by providing a single interface that can be reused anytime a simple implementation of nsIFactory is needed. Here is the interface, and a description of its use.</t>
How To Pass an XPCOM Object to a New Window: If you want to be able to call functions within an XPCOM object from a XUL window's code, you can do so if you pass the XPCOM object as one of the arguments to the window creation method.
How to build a binary XPCOM component using Visual Studio: This is a simple tutorial for building XPCOM objects in C++ using Visual Studio. XPCOM is Mozilla’s cross platform component object model, similar to Microsoft’s COM technology. XPCOM components can be implemented in C, C++, and JavaScript, and can be used from C, C++, and JavaScript. That means you can call JavaScript methods from C++ and vice versa. For more information on the workings of XPCOM look elsewhere.
Interfacing with the XPCOM cycle collector: This is a quick overview of the cycle collector introduced into XPCOM for Firefox 3, including a description of the steps involved in modifying an existing C++ class to participate in XPCOM cycle collection. If you have a class that you think is involved in a cyclical-ownership leak, this page is for you.
Introduction to XPCOM for the DOM: Fabian Guisset <[email protected]>
Language bindings: An XPCOM Language Binding is a bridge between a particular language and XPCOM to provide access to XPCOM objects from that language, and to let modules written in that language be used as XPCOM objects by all other languages for which there are XPCOM bindings.
Monitoring HTTP activity: Gecko includes the nsIHttpActivityObserver interface, which you can implement in your code to monitor HTTP transactions in real time, receiving a callback as the transactions take place.
Storage: Technical review completed.
Using nsCOMPtr: This document is the sum total of everything written down about nsCOMPtr. If you have a question about nsCOMPtr, and this document doesn't answer it, there probably isn't a document that answers it. You'll have to turn to the XPCOM newsgroup or another experienced nsCOMPtr user, or find the answer by experimentation.

Using nsIClassInfo: If you use a C++ class which implements nsIClassInfo from JavaScript, then you don't have to explicitly call QueryInterface on the JavaScript object to access the object's interfaces.
Using nsIDirectoryService: Technical review completed.
Using nsIPasswordManager: Technical review completed.
Using nsISimpleEnumerator
Using the Gecko SDK
Using the clipboard: This section provides information about cutting, copying, and pasting to and from the clipboard.
Weak reference: In XPCOM, a weak reference is a special object that contains a pointer to an XPCOM object, but does not keep that object alive. If the referent object is destroyed before the weak reference, the pointer inside the weak reference is set to nsnull.
Working with Multiple Versions of Interfaces: In this short note we illustrate how one can update an XPCOM module in order for it to work in both Firefox 2 and Firefox 3, even if the interfaces have changed in the interim.
Working with out parameters
XPCOM ABI: XPCOM ABI is the binary interface of XPCOM components. While XPCOM components written in a scripting language (such as JavaScript) can be moved across platforms (such as Windows and OS X) without adaptation, those written in a compiled language (such as C++) require recompilation when moving to a different platform. Often, compiled XPCOM components are called 'binary' or 'native'.
XPCOM Thread Synchronization: XPCOM thread synchronization primitives have the same semantics as those in NSPR, and each method of these synchronization objects (e.g. Mutex::Lock()) has a matching function in NSPR (PR_Lock()). This is no accident, as mozilla:: primitives are merely bare-minimum wrappers around NSPR's.
XPCOM category image-sniffing-services: In versions of Firefox prior to Firefox 3, extensions could add decoders for new image types. However, such decoders relied on servers sending correct MIME types; images sent with incorrect MIME types would not be correctly displayed.
XPCOM glue: The XPCOM Glue is a static library which component developers and embedders can link against. It allows developers to link only against the frozen XPCOM method symbols and maintain compatibility with multiple versions of XPCOM.
XPCOM guide: These articles provide tutorials and usage documentation for XPCOM, including how to use it in your own projects and how to build XPCOM components for your Firefox add-ons and the like.
XPCOM ownership guidelines: ...naturally. If you create a temporary object, obviously it's up to you to destroy it. That's a sure sign of ownership. If you create an object with a longer lifespan, you will own it until you give ownership away.
XPCOM reference: This reference describes the interfaces and functions provided by the XPCOM library. In addition, it details the various helper classes and functions, as well as the components, provided by the XPCOM glue library. The contents herein are oriented primarily toward extension developers and people embedding XPCOM in other projects.
XPCOM tasks: The XPCOM module roughly parallels the C/C++ standard libraries. It overlaps them significantly, but goes beyond them in capabilities. XPCOM sits above the standard libraries. Its role is to extend them with facilities tailored to XPCOM development in general, and specifically the needs of Mozilla. Like the standard libraries, XPCOM must be a fairly self-contained library, so as not to encumber clients with any unnecessary external dependencies.
Xptcall Porting Guide: Original Author: John Bandhauer, 31 May 1999.
Xptcall Porting Status: This is a status page for the multiplatform porting of xptcall. xptcall has a FAQ and a Porting Guide.
already_AddRefed: already_AddRefed in association with nsCOMPtr allows you to assign in a pointer without AddRefing it.
xptcall FAQ: xptcall is a small low level XPCOM method call library. It is implemented using platform specific C/C++ and assembly language code. It is used to facilitate cross language and cross thread method calls. Porting this code is required in order to make Mozilla run on any given platform.

Join the XPCOM community

Choose your preferred method for joining the discussion:

XPCOM

Join the XPCOM community

Document Tags and Contributors