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.

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.

Avoiding leaks in JavaScript XPCOM components: Programmers writing and reviewing JavaScript code in Mozilla should understand how code using XPCOM in JavaScript can leak so that they can avoid leaks. This document attempts to help them do so, first by explaining the underlying concepts, and second by describing a number of common JavaScript patterns that cause leaks.
Creating XPCOM components: This guide is about Gecko, and about creating XPCOM components for Gecko-based applications.
How to build an XPCOM component in JavaScript: If you are looking for Add-on SDK solution for XPCOM JavaScript components then check out platform/xpcom module first.
Inheriting from implementation classes: Given that IDL interfaces map to abstract classes in C++, a common problem when dealing with IDL is when you have an IDL inheritance hierarchy, and a corresponding C++ implementation hierarchy, you run into multiple inheritance. That's not inherently multiple inheritance, though, because you only mix in interfaces (i.e. the problem would not exist with Java's interfaces).
Making cross-thread calls using runnables: In the Mozilla platform, most activities such as layout, DOM operations, content JavaScript, and chrome JavaScript run on the main thread. However, it may be useful for C++ code in the Mozilla platform to run tasks on another thread.
Mozilla internal string guide: Most of the Mozilla code uses a C++ class hierarchy to pass string data, rather than using raw pointers. This guide documents the string classes which are visible to code within the Mozilla codebase (code which is linked into libxul).

mozilla::services namespace: The services C++ namespace offers an easy and efficient alternative for obtaining a service as compared to the indirect XPCOM approach: GetService(), CallGetService(), etc methods are expensive and should be avoided when possible.
Receiving startup notifications: Sometimes it's necessary for XPCOM components to receive notifications as to the progress of the application's startup process, so they can start new services at appropriate times, for example.
XPCOM array guide: Mozilla has many array classes because each array is optimized for a particular usage pattern. This guide describes the available arrays as well as the enumerator classes that can be used to get to them. In this document the term Array refers to a container for multiple objects with a numeric, zero-based index.
XPCOM changes in Gecko 2.0: Several changes that affect XPCOM component compatibility are taking place in Gecko 2. This article details those changes, and provides suggestions for how to update your code.
XPCOM hashtable guide: A hashtable is a data construct that stores a set of items. Each item has a key that identifies the item. Items are found, added, and removed from the hashtable by using the key. Hashtables may seem like arrays, but there are important differences:
XPCOM Stream Guide: In Mozilla code, a stream is an object which represents access to a sequence of characters. It is not that sequence of characters, though: the characters may not all be available when you read from the stream.