This translation is incomplete. Please help translate this article from English
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
already_AddRefedin association with
nsCOMPtrallows you to assign in a pointer without
- 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
nsISimpleinterface). 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
firstname.lastname@example.org 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 build a binary XPCOM component using Visual Studio
- 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.
- 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
- Warning: this document has not yet been reviewed by the DOM gurus, it might contain some errors.
- 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
nsIHttpActivityObserverinterface, which you can implement in your code to monitor HTTP transactions in real time, receiving a callback as the transactions take place.
- nsCOMPtr versus RefPtr
- Gecko code uses both
RefPtras smart pointers. This guide provides some explanation and advice on how to choose between them.
- Observer Notifications
- The following are topics that you can observe during the course of an application. Unless otherwise noted you register for the topics using the
- Setting HTTP request headers
- HTTP is one of the core technologies behind the Web. In addition to the actual content, some important information is passed with HTTP headers for both HTTP requests and responses.
- Storage is a SQLite database API. It is available to trusted callers, meaning extensions and Firefox components only.
- The Thread Manager
- The Thread Manager, introduced in Firefox 3, offers an easy to use mechanism for creating threads and dispatching events to them for processing.
- Troubleshooting XPCOM components registration
- Often the first time you create an XPCOM component, it may fail to register correctly.
- 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
nsCOMPtruser, or find the answer by experimentation.
- Using nsIClassInfo
- If you use a C++ class which implements
- Using nsIDirectoryService
- nsDirectoryService implements the
nsIPropertiesinterface. This implementation will allow you to
- Using nsIPasswordManager
- Technical review completed.
- Using nsISimpleEnumerator
- Using the clipboard
- This section provides information about cutting, copying, and pasting to and from the clipboard.
- Using the Gecko SDK
- Weak reference
- In XPCOM, a weak reference is a special object that contains a pointer to an XPCOM object, but doesnot keep that object alive. If the referent object is destroyed before the weak reference, the pointer inside the weak reference is set to
- 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 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.
- 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.
- xptcall FAQ
xptcallis 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.
- 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.