Playwright Browser Has Been Closed: Fix Mid-Test Deaths

Your test fills a form, clicks submit, and then — browser has been closed. The window is gone, the next action has nowhere to land, and the error reads like the browser simply gave up on life. Re-run and it passes. Run the full file and it fails on a different test. The browser, it seems, closes whenever it pleases.

It does not. In the large majority of cases, your own code closed it: a fixture whose teardown runs too early, a shared context one test destroys while another still needs it, an unawaited close that wins a race against the next action. The remaining cases are real deaths — crashes from exhausted memory, killed processes in containers — but they wear the identical message, which sends teams chasing browser bugs for what are actually ordering bugs.

This article separates murder from natural causes. You will learn the browser-context-page ownership chain, the yield-based teardown pattern that keeps resources alive exactly as long as tests need them, headed-mode debugging that shows the death as it happens, and video/trace capture that preserves evidence past the crash. Vanishing browsers become diagnosable events with named owners.

Browser, Context, Page: Who Owns What

Playwright organizes browser state as a strict hierarchy: the browser (the process) owns contexts (isolated sessions, like incognito profiles with separate cookies and storage), and each context owns pages (tabs). Closing any level destroys everything beneath it — context.close() kills its pages instantly, browser.close() ends the world. Most 'browser has been closed' errors are actually destroyed contexts or pages, with the browser process itself perfectly alive.

In pytest-playwright projects, fixtures manage this hierarchy: a session fixture may own the browser while each test gets a fresh context and page. The failure mode is always ownership confusion — code acting on a level it does not own, or after its owner destroyed it. A helper that closes 'its' page destroys a tab the fixture still plans to use; a teardown that closes the context while a page assertion is queued pulls the floor out mid-step.

Learn to read the error as a question about owners: which level vanished, who owned it, and who destroyed it early? The answer is usually one fixture away. Crashes destroy from the bottom up with no owner at fault; teardown bugs destroy from an explicit close call you can find with grep. Start every investigation by listing the closes — the guilty one is almost always in your own codebase.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()      # the process (library)
    context = browser.new_context()    # an isolated session (study room)
    page = context.new_page()          # a tab (desk)
    page.goto('https://example.com')
    page.get_by_role('button', name='Save').click()
    # Closing cascades DOWNWARD:
    # context.close() kills its pages; browser.close() kills everything.
    page.close()
    context.close()
    browser.close()

# The error means one of these was gone before the action ran.

Teardown Order: Close After Yield, in Reverse

Pytest fixtures with yield split time in two: everything before the yield is setup, the test body runs during the yield, and everything after it is teardown. Code placed before the yield that destroys state — a close, a logout, a navigation away — sabotages the test before its first line. The bug reads as a browser problem because the failure surfaces in the test, but the cause sits in the fixture's setup half.

Correct teardown mirrors setup in reverse: pages close before their contexts, contexts before the browser, each close awaited (or returned) so destruction completes deterministically. Unawaited closes in sync code still race subsequent steps because browser-side teardown is asynchronous — the next test can start acting while the previous world is half-destroyed. Deterministic order means deterministic failures, which means fixable failures.

Scope completes the pattern. Browser process fixtures can be session-scoped (launch once, share the cost), but contexts and pages belong at function scope — one fresh isolated world per test. Function-scoped state cannot be poisoned by neighbors: no test can close, pollute, or navigate another test's pages. Sharing contexts across tests saves seconds of setup and spends hours of debugging; the trade is never worth it outside explicitly documented, read-only scenarios.

import pytest

# BAD: close runs during setup — the test gets a dead page
@pytest.fixture
def dead_page(browser):
    context = browser.new_context()
    page = context.new_page()
    context.close()   # runs BEFORE the test body!
    yield page        # test receives a page in a closed context

# GOOD: setup -> yield (test runs here) -> teardown
@pytest.fixture
def logged_in_page(browser):
    context = browser.new_context()
    page = context.new_page()
    page.goto('https://example.com/login')
    page.get_by_label('Email').fill('qa@example.com')
    page.get_by_role('button', name='Sign in').click()
    yield page        # <-- the test body executes during this yield
    page.close()      # teardown: reverse order of creation...
    context.close()   # ...pages before contexts, every close awaited

Headed Mode: Watch the Browser Die Live

When the browser genuinely dies, you want to watch it happen. Headed mode (headless=False, optionally with slow_mo=100) puts the window on screen so the death is visible: a sudden vanish mid-action means a crash — out-of-memory kill, sandbox violation, driver mismatch — while an orderly absence from the start means teardown never delivered a live page. That single visual distinction routes the investigation correctly in seconds.

Headed runs also perturb timing just enough to separate races from certainties. A failure that vanishes under headed observation was likely a close racing the next action — the slower headed pace lets the action win. A failure that persists headed is deterministic: same line, same owner, same early close. Use the difference diagnostically rather than superstitiously.

Keep a headed-debug recipe in the team's runbook: the exact launch flags, how to run a single test headed, and where to look (window behavior, console output, exit code). Browser deaths are stressful precisely because they feel environmental; a fixed recipe converts panic into procedure. The goal is not to run headed always — it is to make the times you need it count. That slower headed pace is diagnostic data, not superstition — use what it tells you.

Video and Trace: Evidence Past the Crash

Video (record_video_dir) and tracing (tracing.start/stop) are the flight recorders for browser deaths — but both attach to the context, which is exactly what a crash destroys. Configured after the failure, they capture nothing; the recorder must be running before the plane takes off. Arm them at context creation for any suite phase known to be crash-adjacent: canvas-heavy pages, large uploads, memory-hungry dev builds.

Each recorder answers different questions. Video shows the visual sequence — what the page looked like frame by frame until the end — which distinguishes app freezes (page stuck, browser alive) from process deaths (frames stop because nothing renders). Tracing records the action timeline with network, console, and DOM snapshots per step, so you can see the last successful action and the exact call that met the closed browser. Together they usually name the cause outright: the leaking canvas, the 766 MB heap, the navigation to the crashing URL.

Treat evidence as infrastructure with retention policy. Keep video on for retries in CI (record_video_dir plus retain-on-failure semantics in your runner config) and tracing for the flaky subset, so every closed-browser report arrives with its black box attached. Debugging from artifacts takes one pass; debugging from the error string alone takes a week of re-runs hoping to witness the crash.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    # Arm artifacts AT CREATION — before anything risky runs
    context = browser.new_context(record_video_dir='videos/')
    context.tracing.start(screenshots=True, snapshots=True, sources=True)
    page = context.new_page()
    try:
        page.goto('https://example.com/canvas-heavy')
        page.get_by_role('button', name='Render').click()
        # ... risky phase under observation ...
    finally:
        # Stop tracing into a file even if the test body raised
        context.tracing.stop(path='trace.zip')
        page.close()
        context.close()  # video finalizes on context close
    browser.close()

# Replay: python -m playwright show-trace trace.zip
# Videos land in videos/ named per page.

Fixture Patterns That Keep the Browser Alive

Ownership discipline is the policy that ends closed-browser errors: fixtures create and destroy, helpers borrow. A helper receiving a page may act on it — click, fill, assert — but must never close it, navigate it away from under the caller, or stash it in module state for later. The fixture that yielded the page is its sole owner and sole destroyer, after the yield, in reverse order.

Enforce the rule mechanically. Lint or review for close() calls outside fixture teardown files; name helper parameters page to signal borrowing; keep page references out of module globals and class attributes where lifetimes escape test boundaries. When sharing is genuinely needed (an expensive authenticated context for read-only specs), document the owner in the fixture's docstring and forbid closes in every consumer — shared ownership without written rules always ends with someone closing early.

The payoff compounds. Ownership-clean suites isolate failures: a crash or close affects exactly the test that caused it, with artifacts pointing at one owner. Ownership-dirty suites smear every teardown bug across neighbors, producing the moving-failure reports that waste whole sprints. Borrow, do not own; yield, then destroy; write down the exceptions. Three sentences that retire an entire error category.

import pytest
from playwright.sync_api import Page

# Helpers BORROW pages: use them, never close them
def save_form(page: Page) -> None:
    page.get_by_test_id('save-btn').click()
    page.get_by_text('All changes saved').wait_for()
    # NO page.close() here — the fixture owns the page

@pytest.fixture
def app_page(browser):
    context = browser.new_context()
    page = context.new_page()
    page.goto('https://example.com/app')
    yield page
    page.close()
    context.close()

def test_rename(app_page: Page):
    app_page.get_by_label('Title').fill('Q3 plan')
    save_form(app_page)  # borrows the page, returns it alive
    assert app_page.get_by_label('Title').input_value() == 'Q3 plan'

Real Crashes: Memory, Containers, and Drivers

Sometimes the browser really dies, and ownership discipline only proves your innocence — it does not prevent the crash. Real deaths have physical causes: a tab's memory grows until the OS kills the renderer, the container's tiny /dev/shm starves Chromium's shared buffers, a browser and driver version mismatch crashes on launch, or a missing sandbox flag kills the process running as root in CI. Each leaves signatures — OOM killer lines, nonzero exit codes, launch-time failures — that look nothing like teardown bugs once you know where to look.

Containers are the most common crime scene. Default Docker /dev/shm is 64MB, far below what Chromium wants for heavy pages, and the symptom is tabs dying mid-render with no Python exception until the next action touches the corpse. Launch with --disable-dev-shm-usage to spill buffers to /tmp, run as non-root or pass --no-sandbox where policy allows, and size container memory from measured peak usage rather than defaults. These three moves resolve the majority of works-locally-dies-in-CI browser deaths.

Memory discipline inside tests matters too: close pages you open, avoid accumulating contexts across long sessions, and split canvas- or video-heavy flows into smaller tests so each crash's blast radius is one behavior. When a death persists, capture the exit path — browser process logs, container OOM events, the trace's final actions — and fix the resource, not the test. A browser that dies of starvation needs feeding, not retrying.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    # Container-safe launch for CI images (tiny /dev/shm, root user)
    browser = p.chromium.launch(args=[
        '--no-sandbox',            # required when running as root in Docker
        '--disable-dev-shm-usage', # spill buffers to /tmp, not 64MB /dev/shm
    ])
    context = browser.new_context()
    page = context.new_page()
    page.goto('https://example.com/heavy')
    # ... test body ...
    page.close()      # free renderer memory as you go in long flows
    context.close()
    browser.close()