DOM

dom/ contains Gecko's implementation of essentially every Web platform API. It is the largest single subsystem of Firefox by source-file count. Every WebIDL-defined interface (Document, Window, Element, XMLHttpRequest, WebSocket, IndexedDB, MediaSession, Notification, WebGL2, WebGPU, Serial, USB, Bluetooth, …) has its bindings and most of its plumbing here.

Purpose

Implement the W3C/WHATWG DOM standards in C++ (with WebIDL bindings to JS) and integrate them with the rest of Gecko: layout, networking, IPC, JS engine, security model, devtools.

Major sub-areas

Sub-dir	Topic
dom/base/	Core DOM: Document, Element, Node, Window, Event, Range
dom/html/	HTML element classes (HTMLInputElement, HTMLAnchorElement, …)
dom/svg/, dom/mathml/	SVG and MathML
dom/bindings/	The WebIDL → C++ binding generator
dom/canvas/	Canvas2D, WebGL, WebGPU
dom/media/	HTMLMediaElement, MediaSource, EME, WebRTC platform glue
dom/workers/	Web Workers (dedicated, shared, service)
dom/serviceworkers/	Service Worker registration, scope matching, fetch interception
dom/fetch/	fetch(), Request, Response, Headers
dom/xhr/	XMLHttpRequest
dom/websocket/	WebSocket
dom/webtransport/	WebTransport
dom/storage/, dom/localstorage/	localStorage, sessionStorage
dom/indexedDB/	IndexedDB
dom/cache/	The Cache API
dom/quota/	Storage quota manager
dom/notification/	Web Notifications
dom/payments/	Payment Request API
dom/permission/	Permissions API and prompts
dom/security/	CSP, Mixed Content, Referrer Policy, COOP/COEP
dom/ipc/	Content/parent process actors, JSActor, BrowsingContext IPC
dom/locks/	Web Locks API
dom/credentialmanagement/	Credential Management / WebAuthn
dom/midi/, dom/gamepad/, dom/battery/, dom/geolocation/	Hardware/sensor APIs
dom/onnx/, dom/mls/	Newer integrations: ONNX runtime, Messaging Layer Security
dom/system/	OS-specific glue
dom/locales/	Localized strings
dom/manifest/	Web App Manifest

WebIDL bindings

A WebIDL file lives next to the implementation:

dom/html/HTMLInputElement.cpp
dom/html/HTMLInputElement.h
dom/webidl/HTMLInputElement.webidl

dom/bindings/ reads every *.webidl, runs the generator, and produces C++ that:

• Reflects properties as JSNative getters/setters.
• Performs argument coercion (numeric clamping, dictionary parsing, sequence-vs-FrozenArray).
• Calls into the C++ class.

Generated headers go to <objdir>/dom/bindings/.

Key abstractions

Type	Header	Role
mozilla::dom::Document	dom/base/Document.h	The root of a DOM tree
mozilla::dom::Element	dom/base/Element.h	Base class for all elements
nsINode	dom/base/nsINode.h	Base node type (Document, Element, Text, etc.)
nsGlobalWindowInner / nsGlobalWindowOuter	dom/base/nsGlobalWindowInner.h	The JS global, plus pre-/post-navigation pair
BrowsingContext	docshell/base/BrowsingContext.h	Per-tab/iframe browsing context
WindowGlobalParent / WindowGlobalChild	dom/ipc/WindowGlobalParent.h	Per-document IPC actors

Document lifecycle

stateDiagram-v2
    [*] --> Created: nsContentDLF::CreateInstance
    Created --> Loading: BeginLoad
    Loading --> Parsing: nsHtml5Parser
    Parsing --> Interactive: readyState=interactive
    Interactive --> Complete: load event
    Complete --> Unloaded: pagehide
    Unloaded --> [*]

DOM ↔ JS bridge

WebIDL bindings replace XPConnect for modern Web APIs. They:

• Cache JSObject reflectors per DOM object on the JS side.
• Use unified bindings (MOZ_CAN_RUN_SCRIPT) so static analysis can verify GC safety.
• Generate fast paths for common types (USVString, ByteString, Optional<T>, Sequence<T>).

Old XPCOM-bridged interfaces still exist (especially in the parent process), accessible via Cc[...].createInstance(Ci.nsIFoo).

Cross-process DOM

Fission and the multi-process model touch many DOM internals. Each Document is owned by exactly one process; cross-document interaction goes through BrowsingContext (synchronized state across processes) and IPDL/JSActor messages. Many APIs that used to be sync (e.g., synchronous window proxy access) became async or restricted under Fission.

Related

• Process model
• Layout
• SpiderMonkey
• Networking