Process model

Firefox runs as a tree of processes. The parent process owns the UI, the disk, and the network. Web content runs in sandboxed content processes; specialized work goes into other dedicated processes. This page describes each process kind and how they relate.

Process types

Type	Role
Parent (a.k.a. default, browser, chrome, main)	Browser UI, profile, prefs, file I/O when not delegated. Always exactly one.
Content	Hosts web pages. Many concurrent instances (Fission: per-origin).
Privileged content	Trusted internal pages (e.g., about:newtab) isolated from arbitrary web origins.
Web Privileged content	Mozilla-owned web origins (e.g., addons.mozilla.org).
Extension	Hosts WebExtensions.
GPU	Owns the WebRender compositor and graphics device.
RDD (Remote Data Decoder)	Decodes media (video/audio) out-of-process.
Socket	DNS resolution, HTTP/3 (Neqo), TLS handshakes.
Utility	Sandboxed worker for misc tasks (audio decoding, JS-only utilities, generic). Multiple sub-kinds.
Forkserver (Linux)	Pre-forked helper to spawn sandboxed children quickly.

Process kinds are enumerated in xpcom/build/GeckoProcessTypes.h. The parent-side host is ipc/glue/GeckoChildProcessHost.cpp.

Spawning and lifetime

sequenceDiagram
    participant Parent
    participant Launcher as GeckoChildProcessHost
    participant Sandbox as Platform sandbox
    participant Child
    Parent->>Launcher: AsyncLaunch(args, type)
    Launcher->>Sandbox: prepare policy (capabilities)
    Launcher->>Child: fork/exec with file descriptors
    Child->>Child: SetupCrashReporter
    Child->>Child: Initialize XPCOM
    Child-->>Parent: ready (IPDL handshake)
    Parent->>Child: PContent::SetXPCOMProcessAttributes(...)

For details on how IPDL channels are bootstrapped, see IPC and IPDL.

Fission (site isolation)

Fission is the project that splits content per-origin. With Fission enabled, distinct origins (eTLD+1) get distinct content processes, even within a single tab when iframes are cross-origin. Cross-origin iframes show up as RemoteBrowser elements in the chrome process and as separate BrowsingContext children in IPC.

Key entry points:

• docshell/base/BrowsingContext.cpp
• docshell/base/CanonicalBrowsingContext.cpp
• dom/ipc/WindowGlobalParent.cpp, dom/ipc/WindowGlobalChild.cpp
• dom/ipc/ContentParent.cpp, dom/ipc/ContentChild.cpp

Sandboxing

Each child process is sandboxed using OS-specific mechanisms. The implementations live in security/sandbox/:

• Linux: seccomp-bpf + namespaces.
• macOS: sandbox-exec profiles + Mach service brokerage.
• Windows: the sandbox Chromium-derived broker + integrity levels + AppContainer.
• Android: SELinux + Android process isolation.

Levels are tunable via prefs (security.sandbox.content.level, …) for debugging. See Security.

Inter-process actors

Two parallel actor systems coexist:

1. IPDL actors — heavy, per-protocol C++ classes generated from .ipdl files. Used for performance-critical channels and most subsystem-to-subsystem traffic.
2. JSActors (JSWindowActor, JSProcessActor) — declarative, JS-only, lightweight. Used for browser chrome features that need to send a few messages to/from content. See dom/ipc/JSActor.cpp.

How a tab navigates

sequenceDiagram
    participant UI as Browser UI (parent)
    participant DSP as DocShell (parent CanonicalBrowsingContext)
    participant CP as Content process (BrowsingContext)
    participant Net as Networking (parent or socket process)
    UI->>DSP: LoadURI("https://example.com")
    DSP->>Net: NewChannel + AsyncOpen
    Net->>Net: DNS, TCP, TLS, HTTP
    Net-->>DSP: Document bytes (channel events)
    DSP->>CP: PContent::PreallocatedProcessHostId or pick existing
    DSP->>CP: PContent::ConstructBrowser(...)
    CP->>CP: Build DOM, layout, paint
    CP-->>UI: PContent::FrameLoaderEvents

The "process picker" (in ContentParent) decides which content process should host a given navigation, balancing process count, origin, and Fission rules.

Process count tuning

• dom.ipc.processCount — desktop content process pool size.
• dom.ipc.processCount.webIsolated — Fission-isolated origins.
• dom.ipc.processPrelaunch.enabled — pre-warms a content process to reduce navigation latency.
• dom.ipc.processCount.webCOOP+COEP — for sites requesting cross-origin isolation.

Related

• IPC and IPDL
• DOM
• Security
• Fission feature