Contents
1. User's Perspective
1.1. Core Modules
Core modules constitute the basic functionality and feature-set of the program. They are loaded unconditionally at startup.
1.2. Automatic Optional Modules
In addition to core modules, there are a number of optional modules. Some optional modules are enabled by default, and it is these that are termed automatic optional modules. They are loaded before the rc, which gives the user an opportunity to configure any features they provide. They can be prevented from being loaded by a set of preferences.
- FAQ: Why are some optional modules enabled by default and others not?
- Optional modules are enabled by default only if the features they provide are unobtrusive, i.e., they don't cause the program to behave in counterintuitive ways. Page-modes can fall into this category when they can be reasonably judged as an unambiguously beneficial improvement to the website that they affect.
1.3. RC
The user's javascript configuration is loaded after core modules and automatic optional modules. In the rc, other optional modules can be loaded, modules can be configured, or preferences can be set to disable automatic optional modules (for the next restart after evaluation).
1.4. GUI
Last of all, windows and buffers are created. Startup is now done.
2. Under the Hood
As a XULRunner application, the first part of Conkeror's startup process is prescribed by the conventions built into XULRunner. XULRunner looks for certain directory structures and files, and interprets or loads them. Once we get to the components, then Conkeror takes over the startup procedure. We will go over the major points of both stages of this process.
2.1. What XULRunner Does
2.1.1. Application Attributes (application.ini)
The first things that XULRunner does (that we care about) is to read the application.ini file in the root of the Conkeror directory. Its presence and the well-formedness of its contents tell XULRunner that this is a XULRunner application, plus some basic facts like the name and version of the program.
2.1.2. Chrome Namespaces (chrome/chrome.manifest)
This file establishes chrome namespaces, logical paths for referring to the files that constitute the program with chrome URIs. For example, chrome://conkeror/content/ is the logical URI of Conkeror's modules directory.
2.1.3. Loading Preferences
- XULRunner establishes many default preferences
- Conkeror's default prefs are loaded from defaults/preferences/*.js
- User prefs are loaded from the profile.
2.1.3.1. defaults/preferences
This directory contains a number of js scripts which contain pref calls. These are evaluated by Mozilla, establishing default prefs. Some of these prefs control Mozilla's behavior, and others are used by Conkeror itself. Default prefs can be overridden by user prefs.
2.1.3.1.1. defaults/preferences/default-modules.js
The prefs in here list optional modules which are enabled by default. Users can prevent those modules from being loaded by overriding these default prefs with user prefs. The reason that these optional modules are loaded via this mechanism is so that they can be loaded before the rc. Features that they provide can then be configured in the rc.
2.1.4. components
At startup, Mozilla loads all of the js files in components. Conkeror has two main components that form a mutually dependent core: application and command-line. They could be loaded in any order, but it may make most sense to think of it in terms of command-line being loaded first. Command-line explicitly depends on application, but not vice versa.
2.1.4.1. components/command-line.js
Ensures that the application component is loaded, loads default optional modules, loads the rc, and makes windows according to the command line.
2.1.4.2. components/application.js
The application service, which constructs the global scope, which is the conkeror object. Provides the module system, uses the module system to load all of the core modules.