skip to content

In Playwright's Trace Viewer, what do the Before, Action and After snapshots show?

level: middleimportance: must knowfreq 60%

answer

  1. Three tabs bracket one action
  2. Reconstruction, not a photograph
  3. The middle one marks the input point
  4. Hoverable because the nodes are real
  5. Nothing inside them executes

basics

~20 s

They are three recorded DOM states around one action: the page as the call began, the moment input was delivered with the target point marked, and the page once the call returned. Comparing them shows what the action changed.

solid answer

~50 s

Selecting an action in the Trace Viewer gives you three snapshot tabs. **Before** is the page as the call started — this is where you check whether the element you targeted was even present. **Action** is the page at the moment input was delivered, with the input point marked, so you can see exactly where a click landed and on top of what. **After** is the page once the call returned, which tells you whether anything actually happened. They are not screenshots: each one is the recorded **DOM**, re-rendered as a real page, so you can hover elements and inspect them with your browser's own tooling. That also means they are inert — no scripts run, no requests go out, and clicking a link inside a snapshot does nothing. You are looking at a reconstruction of a moment, not a live page.

code

typescript · 7 lines
typescript
import { test, expect } from '@playwright/test';

test('driver marker appears once the order is picked up', async ({ page }) => {
  await page.goto('/orders/8412');
  await page.getByRole('button', { name: 'Track driver' }).click();
  await expect(page.getByTestId('driver-marker')).toBeVisible();
});

go deeper

for a junior

Learn the three names and their order: the page as the call began, the moment of input, and the page after. Comparing the first and last is already most of a diagnosis.

for a middle

Explain that these are recorded DOM re-rendered as a page, not images, and say what follows from that: elements are inspectable, text is selectable, and nothing in them executes.

for a senior

Demonstrate the reading habit — Before to confirm the target existed, Action to see where input landed, After to see whether anything moved — before you touch any other tab.

for a principal

Know where the reconstruction stops paying off, such as canvas-drawn and cross-origin content, so your team does not build a debugging culture that assumes every failure is visible in a snapshot.

## Three snapshots, one action Every action row in the Trace Viewer — a `click()`, a `fill()`, an `expect()` — carries up to three snapshots of the page, presented as tabs above the snapshot pane. Together they bracket the call: what the page was, what it was at the instant of input, and what it became. | Snapshot | Captured | The question it answers | |---|---|---| | **Before** | As the call started | Was the target there at all, and what state was the page in? | | **Action** | At the moment input was delivered, with the point marked | Where did the click actually land, and on top of what? | | **After** | Once the call returned | Did anything change as a result? | The **Action** snapshot only exists for calls that deliver input. An assertion or a navigation has a Before and an After but nothing meaningful to mark in between. ## They are DOM, not pixels This is the part candidates most often get wrong. A snapshot is the **recorded DOM tree plus the resources needed to paint it** — stylesheets, images, fonts — re-rendered by the viewer as an actual page in an iframe. Practical consequences: - You can **hover and inspect elements** inside the snapshot with your browser's own element tooling, because they are real nodes with real attributes. - Text in a snapshot is **selectable**; a screenshot's text is not. - Content that lives entirely in a `<canvas>` — a driver map drawn pixel by pixel — reconstructs poorly, because there is no DOM describing what was painted. - The reconstruction is a **moment**, not a recording. Animations, timers and video are frozen wherever they were. ## What does not work inside a snapshot Because nothing is live: - Scripts do not execute, so a menu that opens on click will not open. - No requests leave the page; the network is not connected to anything. - Clicking a link does nothing useful — you have not navigated, you are still inside a reconstruction. - State that was never in the DOM, such as a variable held in a component's memory, is simply absent. ## Reading a pair of snapshots On a food-delivery order tracker whose test clicks **Track driver** and then asserts the driver marker is visible, the three snapshots settle the failure in seconds: 1. Open **Before** on the click. If the button is missing or covered by a cookie banner, the failure is upstream of the click and nothing after it matters. 2. Open **Action** and read where the marked input point landed. A click that landed on an overlay instead of the button looks exactly like a passing click in a screenshot and obvious here. 3. Open **After**. If a spinner replaced the button, the click worked and the problem is what the app did next. If the page is byte-for-byte the Before state, the click hit something that ignored it. 4. Only then move to the other tabs — the recorded call, its log, the console and the network — to explain *why* the change you saw, or did not see, happened. ## Why this beats a screenshot at the end A single end-of-test screenshot shows you the wreckage. The snapshot triptych shows you the transition, and transitions are where the bug is. Being able to say "the element was present in Before, the input point landed two hundred pixels above it in Action, and After is unchanged" is a complete diagnosis of a mis-targeted click that no end-state image can give you. ## Misreadings to avoid - **"The snapshot proves the user saw this."** It proves the DOM held this. Off-screen or transparent nodes are still in the tree. - **"After is the end of the test."** After belongs to one action. The very next action has its own Before, which may already differ. - **"The page is blank, so the app crashed."** A snapshot can render thin when the recorded resources cannot be reconstructed, particularly for canvas-heavy or cross-origin content.

  • Why does a page section drawn on a canvas look wrong in a Trace Viewer snapshot?
    Because a snapshot reconstructs the recorded DOM, and a canvas holds no DOM describing what was painted into it — only the element itself. A driver map rendered on a canvas therefore reappears empty or stale, which is a limitation of the reconstruction, not evidence that the map failed to render during the run.
  • An action row has no Action snapshot at all. What does that tell you?
    That the call delivered no input point to mark — assertions, navigations and waits are recorded with Before and After only. It is not a sign the trace is damaged or that capture was misconfigured.

Think of a shutter: Before is what the photographer was aiming at, Action is the frame at the instant the shutter fired with the crosshair still visible, and After is what the scene looked like once it closed.

saying these in an interview costs you the question

  • Calls the snapshots screenshots taken around the action
  • Expects scripts and network to work inside a snapshot
  • Thinks the After snapshot shows the end of the test
  • Treats a snapshot as proof a user could see the element
  • Assumes an empty canvas in a snapshot means the app broke
  • Ignores Before and reads only the final state