new·Earn with mozg — 20% of every monthSend somebody here and take a fifth of every plan payment they make, for as long as they keep paying — not a bounty on the first invoice. Your handle is the link, the window is thirty days, and the commission lands on your balance the second they pay. Free to join: if you have signed in, you already have the link. mozg.sh/earnall news →
mozg.beta
Sign in

Playwright · API reference · all subjects

tracing & debugging

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

testInfo.attach() for accessibility scan results

testInfo.attach() can be used to attach the full accessibility scan results as a test attachment for debugging. The attachment is passed with a body (JSON.stringify of results), and contentType of 'application/json'.

playwright-cli tracing-start command

The command 'playwright-cli tracing-start' begins recording a trace. This creates a .playwright-cli/traces/ directory with trace files.

playwright-cli tracing-stop command

The command 'playwright-cli tracing-stop' stops recording the current trace and saves all captured data to trace output files.

Trace output directory structure

When tracing starts, Playwright creates a .playwright-cli/traces/ directory containing: trace-{timestamp}.trace files (main trace with action logs and DOM snapshots), trace-{timestamp}.network files (network activity log), and a resources/ directory (cached resources for replay).

trace-{timestamp}.trace file contents

The main trace file contains: every action performed (clicks, fills, navigations), DOM snapshots before and after each action, screenshots at each step, timing information, console messages, and source locations.

trace-{timestamp}.network file contents

The network log file contains complete network activity: all HTTP requests and responses, request headers and bodies, response headers and bodies, timing information (DNS, connect, TLS, TTFB, download), resource sizes, and failed requests and errors.

resources directory in traces

The resources directory caches resources needed for trace replay, including images, fonts, stylesheets, scripts, response bodies, and other assets needed to reconstruct page state.

What traces capture - comprehensive list

Traces capture: Actions (clicks, fills, hovers, keyboard input, navigations), DOM (full DOM snapshot before/after each action), Screenshots (visual state at each step), Network (all requests, responses, headers, bodies, timing), Console (all console.log, warn, error messages), and Timing (precise timing for each operation).

Trace vs Video vs Screenshot comparison

Trace format (.trace file) provides DOM inspection, network details, and step-by-step replay with medium file size. Video (.webm) has continuous replay but no DOM inspection or network details, with large file size. Screenshot (.png/.jpeg) is single frame with small file size but no DOM inspection, network details, or replay capability.

Trace best practice - capture entire flow

Always trace the entire flow, not just the failing step, to get complete context when debugging. Start tracing before the problem occurs and include all steps leading to the issue.

Trace disk space cleanup

Traces can consume significant disk space. Use 'find .playwright-cli/traces -mtime +7 -delete' to remove traces older than 7 days.

Tracing limitations

Traces add overhead to automation. Large traces can consume significant disk space. Some dynamic content may not replay perfectly.

Debugging failed actions with traces

To debug why an action fails, start tracing before performing the action sequence, then stop tracing. The trace shows the exact DOM state when the action was attempted, allowing analysis of why it failed.

Analyzing performance with traces

Traces can be used to identify performance bottlenecks by viewing the network waterfall to identify slow resources and timing information for each operation.

Give your agent this brain