You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Source code directories overview

by Daniel Howard

With special thanks and credit to:
Heikki Toivonen, 11-Nov-1999
Hervé Renault (for the French translation), 16-Nov-1999

updated by Michael Kaply 2-June-2005 - work in progress.

This document is a guide for developers to the directory structure of the Mozilla source code tree. It gives a bird's eye view of the source code so a developer can get a good idea what is in Mozilla and where to find things. It is a good document for a new Mozilla developer to start learning about the Mozilla code base.

This document contains material for SeaMonkey, Firefox, and Toolkit.

It is a living document which is updated monthly according to changes in the Mozilla source tree.

See also similar information on the Mozilla Developer Center, http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Directory_Structure

Introduction: Common Subdirectories

A common naming scheme is used throughout the Mozilla source trees. At the top level is the name of the product (e.g. seamonkey). At the second level is the name of the module (e.g. the editor directory in seamonkey). The third level is where the common naming scheme usually takes over. Many third level directories contain the base, the public and the idl directories. Although not required, these common names are typically used for a common purpose. If files can be grouped into submodules, they are usually put in their own third level directory and given a unique name (e.g. txmgr in the editor directory in seamonkey). Beneath this third level directory, there may be fourth level base, public and idl directories. Thus, the scheme is recursive; it can apply to submodules, sub-submodules and so on.

  • base contains the basic (core) functionality for the module. Base contains all the source code that cannot be categorized into a submodule.
  • build contains any special makefiles for building the particular module.
  • doc contains any documentation associated with this module.
  • idl contains the XPIDL (Cross Platform Interface Definition Language) interface files. Interfaces are used so functionality can be available to both Javascript scripts and C++ code with as little effort as possible. XPIDL files have their own mini-language and processing tools.
  • public contains source code that will be exported to the dist/include directory. They are not all necessarily public in the general sense; some are only meant for internal use in a certain module. As more code is written with or converted to XPIDL interfaces, the value of the public directory diminishes.
  • src contains the bulk of the source code.
  • tests contains C++ harnesses, HTML or XUL that exercise this module.
  • tools contains scripts for automatically generating certain source code and other special tools for building this module.

There are also platform dependent subdirectories which contain source code for specific platforms.

  • windows contains source code for Windows 95, Windows 98 and Windows NT 4.0.
  • mac contains source code for MacOS: both the PowerPC and 68000 versions.
  • gtk contains source code for GTK+ (a.k.a. the GIMP Toolkit) which runs on X-Windows on Unix.
  • motif contains source code for Motif, a toolkit which runs on X-Windows on Unix.
  • os2 contains source code for OS/2 Warp.
  • rhapsody contains source code for Mac OS X Server (which is based on NeXTStep which is based on X-Windows on Unix) using Yellow Box (Cocoa).
  • beos contains source code for BeOS.
  • qt contains source code for the QT toolkit, a C++ class library which runs on X-Windows on Unix, Windows 95, Windows 98 and Window NT 4.0.
  • photon contains source code for Photon, a microkernel windowing system used in several real-time operating systems from QNX Software Systems Ltd.

SeaMonkey

SeaMonkey is the development name for the Mozilla browser suite.

  • accessible contains code to support Microsoft Active Accessibility and Sun's ATK accessibility API for Linux.
  • browser contains the code for Firefox. This will be covered below.
  • build contains scripts (usually Perl) and programs used by the Mozilla build team for building and managing the Mozilla code base. These programs coordinate the running of makefiles and the creation of the dist directory.
  • calendar contains the code for the various Mozilla calendar apps and extensions.
  • caps contains C++ interfaces and code for determining the capabilities of content based on the security settings and certificates (e.g. Verisign).
  • chrome contains the toolkit chrome registry.
  • config contains scripts and programs used by Mozilla developers to manipulate the code base and to perform special actions inside makefiles. These programs are used for code level things instead of build level things (which are a stored in the build directory).
  • content was split off from layout and contains objects as they are exposed to the DOM.
  • db contains C++ code for the mdb/Mork database which is a low-level, general-purpose and cross-platform file library. It is used to store mail box data, news data and global history data. It has not been updated to support XPCOM yet. This code originated in the Mozilla Classic code base.
  • dbm contains C code for managing, reading and writing hash tables. It is used for the auto-completion feature on the URL edit box (stored in netscape.hst in Mozilla Classic) and for the cached pages index (stored in fat.db in Mozilla Classic). This code originated at UC Berkeley.
  • directory contains the LDAP SDK.
  • docshell contains C++ interfaces and code for loading and displaying a single web page (e.g. scroll). The embedding code wraps this code with higher level browser functions like forward, back and history.
  • dom contains C++ interfaces and code for implementing and tracking DOM (Document Object Model) objects in Javascript. It forms the C++ substructure which creates, destroys and manipulates built-in and user-defined objects according to the Javascript script. For example, if the Javascript script adds a user-defined attribute to the document (e.g. document.goofy = 1), this code will create the "goofy" node, put it on the "document" node and manipulate it according to any later Javascript commands.
  • editor contains C++ interfaces, C++ code and XUL for the embeddable editor component which can edit both plain text and HTML. It is used for the HTML editor (i.e. Composer in Mozilla Classic), for plain text and HTML mail composition and for text fields and text areas throughout the product. The editor is designed like a "browser window with editing features" with extra classes for editing text and managing undo/redo.
  • embedding contains C++ interfaces and code for generic high-level browser functions (e.g. forward, back, history). The webshell code wraps these interfaces according to the particular platform and way (e.g. ActiveX) that is being supported.
  • extensions contains C++ interfaces, C++ code, XUL and Javascript code for various add-ins that are related to browsing. These include: cookies, IRC, wallet, DOM Inspector, P3P, schema validation, spellchecker, transformiix, typeaheadfind, JavaScipt debugger, XForms, etc.
  • gc contains C code for the Boehm garbage collector. It is not used in the final product: it is used to find memory leaks and track memory usage during development. This code originated from code written by Hans-J. Boehm with support from National Science Foundation, DARPA, Xerox and SGI (at various times).
  • gfx contains C++ interfaces and code for platform independent drawing and imaging. It can be used to draw rectangles, lines, images, etc. Essentially, it is a a set of interfaces for a platform-independent device (drawing) context. It does not handle widgets or specific drawing routines; it just provides the primitive operations for drawing.
  • intl contains C++ interfaces and code for supporting localization. It contains code for various character sets, locale formats (e.g. the format of the date and time for different cultures) and other localization facilities.
  • ipc contains
  • jpeg contains C code for reading/writing JPEG images. This code originated as the reference implementation for the JPEG specification from the Independent JPEG Group.
  • js contains C code for tokenizing, parsing, interpretting and executing Javascript scripts. This code originated in Mozilla Classic.
  • l10n contains code for building localizations.
  • layout contains the C++ interfaces and code for the layout engine. The layout engine decides how to divide up the "window real estate" among all the pieces of content. It resizes and aligns pieces of content according to the CSS1 and CSS2 (cascading style sheets), alignment styles and the content itself. It does not actually render the content; it just assigns different pieces of the window to various content items. This is known as "reflowing" the content. This code is also known by the names, "NGLayout" and "Gecko."
  • lib contains C++ code used for reference by developers in programming the Mac. It is not used. It shows how to embed the Mozilla browser in a Mac application as well as some sample file-handling code from Apple.
  • mailnews contains C++ interfaces and code for the mail and news component (i.e. Messenger in Mozilla Classic). It includes all the code for managing mail, reading newsgroup messages, importing other mail formats, composing new messages and so on.
  • modules contains C code for various different browsing related features that are built into Mozilla. It contains code for handling various image formats (e.g. .PNG, .GIF), allowing drop-in Java virtual machines (called OJI, for "Open Java Interface"), supporting plug-ins and reading various compression formats (e.g. JAR, ZIP, ZLIB). This code originated from Mozilla as well as various different companies and individual people.
  • netwerk contains C++ interfaces and code for low-level access to the network (using sockets and file and memory caches) as well as higher-level access (using various protocols such as http, ftp, gopher, castanet). This code is also known by the names, "netlib" and "Necko."
  • nsprpub contains C code for the cross platform "C" Runtime Library. The "C" Runtime Library contains basic non-visual C functions to allocate and deallocate memory, get the time and date, read and write files, handle threads and handling and compare strings across all platforms. This code is also known by the name, "nspr" and "Netscape Portable Runtime". This code originated in Mozilla Classic.
  • other-licenses contains code that does not fall under the MPL, including branding, libical and stubs for 7zip.
  • parser contains the HTML parser and the XML parser (expat.).
  • plugin contains code for the MRJ plugin on Mac.
  • profile contains C++ interfaces, C++ code, XUL and Javascript scripts for creating new user profiles, managing existing user profiles, migrating profiles from Mozilla Classic and using default profiles for popular ISPs (e.g. Earthlink and Concentric Networks).
  • rdf contains C++ interfaces and code for accessing various data and organizing their relationships according to RDF. RDF stands for "Resource Description Framework" which is an open standard. This code reads and writes data from and to the local file system, databases, the Internet or any other source using a URL-like syntax.
  • security contains the security modules including NSS and PSM.
  • storage contains an implementation of sqLite3.
  • suite will contain files specific to the Mozilla suite.
  • sun-java contains C code so Mozilla can communicate with the Sun JVM (Java Virtual Machine). It does not include the code for the virtual machine itself, though.
  • themes contains the default themes for Mozilla, modern and classic.
  • toolkit contains the code for the toolkit used for Firefox, Thunderbird and other standalone applications. This will be covered below.
  • tools contains C++ code for the Linux-only Leaky tool. Leaky can help detect memory leaks and XPCOM reference counting problems.
  • uriloader contains C++ interfaces and code for invoking the correct viewer for the content contained at a certain URL. For example, if this code determines that the content is a mail message, it looks up the appropriate listener (probably Netscape Messenger) and passes the mail message to it for display. It is generic and can hand the content off to internal components (like Messenger), to plug-ins or helper apps.
  • view contains C++ interfaces and code for different types of views (e.g. scrolling view). A view contains content but does not contain the title bar, borders or other decorations (which are contained by frames). This code serves to manipulate the individual content that it contains. For example, a scrolling view will find out the scroll bar positions and tell its content where to draw according the scroll bar thumbs.
  • webshell contains C++ interfaces, C++ code, Linux shell scripts and other files for embedding Mozilla in other programs on various different platforms in various different ways (e.g. as plug-in, as ActiveX component, as XPCOM classes).
  • widget contains C++ interfaces and code for platform independent controls (widgets), such as scroll bars, radio buttons and list boxes.
  • xpcom contains the low-level C++ interfaces, C++ code, C code, a bit of assembly code and command line tools for implementing the basic machinery of XPCOM components (which stands for "Cross Platform Component Object Model"). XPCOM is the mechanism that allows Mozilla to export interfaces and have them automatically available to Javascript scripts, to Microsoft COM and to regular Mozilla C++ code. Some low-level XPCOM classes and interfaces are also defined here (e.g. the event loop for all platforms). XPCOM is compatible and very similar to Microsoft COM (although XPCOM is cross-platform).
  • xpfe contains the C++ interfaces, C++ code and XUL for implementing the "Cross Platform Front End." Essentially, this is where the Mozilla program starts and manages other components to accomplish tasks. This code contains very little platform dependent code; it relies on other components to provide platform independent interfaces to platform specific functionality.
  • xpinstall contains the C++ interfaces and code for implementing the SmartUpdate feature from Mozilla Classic. XPInstall provides code for downloading files, uncompressing them and installing them in a platform independent way.
  • xulrunner contains code for XUL Runner.

Firefox

Firefox is contained in the browser directory

  • app contains contains code to build the firefox executable.
  • base contains the XUL and branding code.
  • components contains Firefox specific components like history, bookmarks, preferences, migration, sidebar..
  • configcontains build scripts for Firefox.
  • extensions contains code for making certain extensions work.
  • installer contains the Firefox installer code.
  • locales contains the files that are translated for Firefox.
  • themes contains Firefox themes.

Toolkit

Toolkit is used by the standalone products.

  • components contains the alerts, autocomplete, command line interface, console, cookies, download manager, filepicker, history, password manager, typeaheadfind, view source, etc.
  • content contains XUL specific to the toolkit.
  • library contains libXUL work.
  • localescontains files that are translated.
  • mozappscontains shared application stuff.
  • obsoletecontains obsolete stuff.
  • profilecontains the profile manager
  • themescontains themes as they relate to toolkit things.
  • xreis the XUL runtime engine. This directory contains the code for initializing the toolkit.