How Firefox Uses sessionstore.jsonlz4 for Crash Recovery

This article provides a technical breakdown of how the Mozilla Firefox web browser prevents data loss during unexpected crashes using the sessionstore.jsonlz4 file architecture. It covers the file's compression format, the continuous background saving mechanism, and the exact methods Firefox uses to record and restore open windows, tab histories, page scroll positions, and unsubmitted text in web forms.

The File Format and Continuous Backup System

The sessionstore.jsonlz4 file is a compressed data file located in the user's Firefox profile directory. It consists of a standard JSON (JavaScript Object Notation) text structure that has been compressed using Mozilla's custom implementation of the LZ4 algorithm, which prioritizes fast decompression speeds during browser startup.

sessionstore.jsonlz4 only exists in the main profile folder when Firefox is closed normally. While the browser is actively running, the session management system operates inside the sessionstore-backups folder. As you browse, Firefox continuously writes your current state to a temporary working file named recovery.jsonlz4 every 15 seconds. If Firefox crashes, it detects that the main sessionstore.jsonlz4 file was never generated at shutdown and automatically falls back to the latest recovery.jsonlz4 file to rebuild the session.

Restoring Open Windows and Tabs

The core structure of the session file is a hierarchical JSON tree. At the top level, the file contains a windows array, which holds separate objects for every browser window that was open prior to the crash.

To restore the visual layout and navigation state, Firefox records the following parameters inside each window object:

  • Window State: The exact screen coordinates, height, width, and whether the window was maximized, minimized, or in full-screen mode.
  • The Tabs Array: Each window object contains a tabs array. Every tab is represented as an individual object containing its current state, such as whether it is pinned, muted, or hidden.
  • Tab History (entries): Firefox does not just save the final URL you were looking at. It saves an entries array for every tab, which logs the chronological browsing history of that specific tab. This allows the browser's "Back" and "Forward" buttons to function normally even after a crash restoration.

Restoring Scroll Positions

When a webpage reloads after a crash, losing your place on a long article or document is prevented by the scroll property stored within each tab's data object.

Whenever you scroll a webpage, Firefox's internal rendering engine tracks the viewport's exact position. During the 15-second backup interval, Firefox records the horizontal (X) and vertical (Y) pixel offsets of the page. This data is saved as a simple coordinate string (for example, "0,1450"). If a webpage contains nested scrollable elements, such as internal frames (<iframe>), the JSON structure maps the scroll coordinates for those individual child frames as well. Upon restoration, once the page layout finishes rendering, Firefox automatically instructs the viewport to jump to those exact pixel coordinates.

Recovering Unsubmitted Form Text

To prevent users from losing typed data in comment boxes, emails, or applications, Firefox actively monitors the Document Object Model (DOM) of loaded webpages for user input.

When you type into standard HTML <input> or <textarea> fields, or interact with <select> dropdowns and checkboxes, Firefox records these changes under the formdata object within the active tab's JSON entry. It accomplishes this safely and accurately through three mechanisms:

  • ID Mapping: If the HTML form element has a unique id or name attribute, Firefox pairs that identifier directly with the text string you typed.
  • XPath Mapping: If a web developer did not assign an ID to a text box, Firefox generates an XPath (XML Path Language) expression. This acts as a structural map (e.g., /xhtml:html/xhtml:body/xhtml:div[2]/xhtml:form/xhtml:textarea[1]) so the browser knows the exact location of the text box within the webpage's code.
  • Security Exclusions: To protect user privacy, Firefox's session store engine explicitly ignores any input field marked as type="password" or fields where the website has strictly disabled autocomplete for security reasons.

The Crash Recovery Execution Process

When you launch Firefox after an unexpected crash, the recovery process executes in a strict sequence:

  1. Detection: Firefox checks the profile lock files, realizes the previous session terminated abnormally, and locates the most recent lz4 session file.
  2. Decompression and Parsing: The browser decompresses the LZ4 binary data directly in memory and parses the raw JSON text into a JavaScript object.
  3. UI Reconstruction: Firefox reads the windows and tabs arrays, opens the required number of browser windows at their saved screen coordinates, and populates the tab bar. To save memory, background tabs are often placed in a pending state, meaning their titles and icons are displayed, but the webpage will not fully load until you click on the tab.
  4. DOM Injection: For the active tab, Firefox fetches the webpage over the network (or from the local cache). As soon as the HTML DOM finishes building, the browser iterates through the saved formdata object, locates the matching IDs and XPaths on the page, and injects the saved text strings back into the input fields.
  5. Viewport Adjustment: Finally, the browser reads the scroll coordinate values and moves the page viewport to the exact pixel offset recorded before the crash.