Test sessions

A session records everything a tester sees and does — DOM changes, scrolling, the mouse trail, clicks — and attaches the replay to the report that concludes it.

Starting and ending

• In the widget panel: Start test session. A pulsing REC badge with a live timer sits next to the button for the whole session — testers always know they're recorded.
• Sending a report ends the session and ships the recording with it. A failed send keeps the session running so nothing is lost.
• End test session in the panel discards without sending.

Or drive it programmatically, e.g. when a QA scenario starts:

import { startSession, endSession } from "@tracebird/web";

await startSession();   // recorder chunk loads on demand
// … tester walks the scenario, sends a report from the widget …
endSession();           // only needed if no report was sent

What gets recorded

• rrweb event stream — DOM mutations, scroll, viewport, mouse movement (sampled at 40 ms). Inputs are masked at the source; the widget itself is excluded.
• Click journey — a timestamped list of what was clicked (button “Pay”), readable at a glance without playing the video.

In the dashboard, the report's Replay tab plays the stream in a frame locked to the tester's viewport — scroll is replayed, the viewer can't interact — with play/pause, 1–8× speed, skip-inactive and a timeline.

Sessions survive navigation

Full page loads don't interrupt a session. State persists in sessionStorage: on every load the SDK resumes the session (same id, running timer), archives the previous page's events as a compressed segment, and merges everything into one continuous recording at send time.

Limits

• 20 000 events per page — long sessions stop growing, not crash.
• 3 MB gzipped recording cap per report.
• 200 click breadcrumbs; under storage pressure the oldest video segment is dropped before the session is ever killed.