How to Fix Playwright Target page context or browser has been closed

TL;DR

To fix Playwright Target page context or browser has been closed, locate the earliest lifecycle event and correct its owner. Await all page work before a test or fixture finishes, remove manual closes of Playwright Test fixtures, keep pages and contexts isolated across workers, and inspect browser disconnect or page crash evidence when no code path closes them.

Key Takeaways

• The error means code used a Playwright object after its page, context, browser, or underlying process was no longer available.
• Find the first close, teardown, disconnect, or crash event, not only the later action that reported the closed target.
• Await every task that uses a fixture before the test function returns because fixture teardown begins when the test ends.
• Let Playwright Test own its page, context, and browser fixtures unless manual lifecycle control is an intentional requirement.
• Register popup, download, response, and new-page waits before triggering the event to prevent race conditions.
• Never share mutable page or context globals across parallel tests, and close resources in child-to-parent order.
• Use traces, event listeners, server logs, process exit evidence, and resource metrics to separate code-driven closure from browser crashes.

To fix playwright Target page context or browser has been closed, identify which lifecycle owner ended the page, browser context, or browser before a later asynchronous operation finished. The visible failure often appears at click(), goto(), waitForEvent(), or an assertion, but the root cause is usually an earlier close, missing await, completed fixture, parallel teardown, popup race, or browser process crash.

This is an ordering problem until evidence proves it is a process problem. Start with the first lifecycle event, not the last stack frame. This guide shows how Playwright's resource hierarchy works, how test fixture teardown interacts with asynchronous work, how to handle popups and downloads safely, and how to diagnose CI-only disconnects without papering over them with retries.

TL;DR

The simplest correct Playwright Test pattern is:

import { test, expect } from '@playwright/test';

test('saves the profile', async ({ page }) => {
  await page.goto('/profile');
  await page.getByLabel('Display name').fill('QA Engineer');
  await page.getByRole('button', { name: 'Save' }).click();
  await expect(page.getByRole('status')).toHaveText('Profile saved');
});

Do not call page.close(), context.close(), or browser.close() when those objects came from Playwright Test fixtures.

1. Understand the Page, Context, and Browser Hierarchy

A Browser owns one or more BrowserContext objects. A context owns pages. Closing a parent invalidates its descendants: closing a browser closes all contexts and pages, while closing a context closes its pages. Closing one page does not normally close sibling pages or the parent context.

Playwright Test supplies built-in browser, context, and page fixtures. The runner manages their setup and teardown according to fixture scope. The normal test should use them and finish all work before returning. Manual library scripts, by contrast, own the browser they launch and must close it explicitly.

The error message groups target types because the underlying protocol connection can no longer perform the requested operation. It may not state which owner closed first. A page action can report the grouped message after the browser process disconnected, a context teardown closed the page, or explicit code called page.close().

Navigation does not itself invalidate a locator because locators re-resolve in the current page. A normal same-page redirect is not equivalent to closing the page. However, an application can close a popup through window.close(), or a browser can replace a tab in a special flow. Observe events rather than inferring from the URL change.

Draw the ownership chain for the failing object. Ask who created it, which scope owns it, which async tasks still use it, and which code is allowed to close it.

2. Root-Cause and Evidence Matrix

The same final message can represent very different failures. Use timing and events to classify it.

Search the repository for browser.close(, context.close(, and page.close(, including helper and teardown code. Also search for unawaited page methods, void calls, timers, and async array callbacks. The line that throws is often only the first code to notice the invalid resource.

3. Fastest Way to Fix Playwright Target page context or browser has been closed

First, run the failing test alone with one worker and tracing. Add temporary lifecycle logging near the owner, then find the earliest close or disconnect.

import { test } from '@playwright/test';

test('diagnoses target lifecycle', async ({ page, context, browser }) => {
  page.on('close', () => console.log('page closed'));
  page.on('crash', () => console.log('page crashed'));
  context.on('close', () => console.log('context closed'));
  browser.on('disconnected', () => console.log('browser disconnected'));

  await page.goto('/dashboard');
  await page.getByRole('button', { name: 'Refresh' }).click();
});

Run the exact project and focused test:

npx playwright test tests/dashboard.spec.ts --project=chromium --workers=1 --trace=on

Lifecycle logs are temporary diagnostics. Avoid noisy global logging in every passing job. If page closed fires immediately after the test ends and a helper then fails, the helper outlived the fixture. If browser disconnected fires during the test with no close call, inspect the browser process and runner. If the issue disappears with one worker, investigate shared resources rather than declaring it fixed.

Remove test retries during the focused diagnosis if they obscure the first attempt, but preserve the original report. Retries can generate secondary teardown errors that distract from the first failure.

4. Await Every Operation Before the Test Ends

Playwright Test tears down test-scoped fixtures after the test function resolves or rejects. Any unawaited task that still uses page may resume after teardown and report that its target is closed.

Incorrect:

async function verifyDashboard(page: import('@playwright/test').Page): Promise<void> {
  await page.getByRole('heading', { name: 'Dashboard' }).waitFor();
}

test('opens dashboard', async ({ page }) => {
  await page.goto('/dashboard');
  verifyDashboard(page); // Promise is not awaited.
});

Correct:

test('opens dashboard', async ({ page }) => {
  await page.goto('/dashboard');
  await verifyDashboard(page);
});

Return promises from helpers and annotate them. Enable TypeScript and lint rules that catch floating promises where possible. Do not prefix a page task with void unless it is intentionally detached and does not use test-scoped resources.

Event handlers deserve special care. Playwright event emitters do not automatically make the test await async listener bodies. If the listener performs required assertions or page work, capture an explicit promise through waitForEvent or coordinate completion yourself.

Also await assertions. Locator assertions return promises. Omitting await can let the test end before the assertion completes, producing a false pass, unhandled rejection, or closed-target error during teardown.

5. Replace Async forEach and Untracked Concurrency

JavaScript Array.prototype.forEach does not await promises returned by its callback. A test can finish while each callback continues using the page.

Incorrect:

const labels = ['Name', 'Email', 'Role'];
labels.forEach(async (label) => {
  await expect(page.getByLabel(label)).toBeVisible();
});

Sequential and easy to diagnose:

for (const label of labels) {
  await expect(page.getByLabel(label)).toBeVisible();
}

Concurrent when the operations are independent and read-only:

await Promise.all(
  labels.map((label) => expect(page.getByLabel(label)).toBeVisible()),
);

Do not parallelize actions on one page casually. Concurrent clicks, navigations, and form mutations can race even when every promise is awaited. Browser interactions are usually clearer in user order. Use concurrency for independent waits only when their event relationship is understood.

Timers are another source. A setTimeout(async () => ...) callback can outlive the test. Replace it with Playwright's retrying assertions, a direct awaited promise, or application-state synchronization. Fixed delays do not give the runner ownership of the delayed callback.

If a helper starts a background observer, it must expose a stop and completion contract. Stop it before fixture teardown and await its completion. Fire-and-forget tasks should not retain Page, Locator, or BrowserContext references.

6. Let Playwright Test Fixtures Own Their Resources

When a test receives page, context, or browser as a fixture argument, the runner owns its lifecycle. Closing it manually can break the current test, later hooks, or other code using the fixture.

Incorrect:

test('checks account', async ({ page, browser }) => {
  await page.goto('/account');
  await browser.close();
  await expect(page.getByRole('heading', { name: 'Account' })).toBeVisible();
});

Correct:

test('checks account', async ({ page }) => {
  await page.goto('/account');
  await expect(page.getByRole('heading', { name: 'Account' })).toBeVisible();
});

Use a manually created context when the scenario needs another isolated session, and close only what the test created:

test('supports two isolated users', async ({ browser }) => {
  const adminContext = await browser.newContext();
  const userContext = await browser.newContext();

  try {
    const adminPage = await adminContext.newPage();
    const userPage = await userContext.newPage();
    await Promise.all([
      adminPage.goto('/admin'),
      userPage.goto('/home'),
    ]);
  } finally {
    await userContext.close();
    await adminContext.close();
  }
});

The test owns the two contexts but not the fixture browser. Closing contexts in finally keeps cleanup deterministic even when an assertion fails.

7. Design Custom Fixtures with Correct Teardown Boundaries

A custom fixture performs setup, calls use(value), then tears down after use returns. Code after await use(...) must assume the dependent test and fixtures have finished. Code started before use must be stopped and awaited during teardown.

import { test as base, expect, type Page } from '@playwright/test';

type Fixtures = {
  adminPage: Page;
};

export const test = base.extend<Fixtures>({
  adminPage: async ({ browser }, use) => {
    const context = await browser.newContext({
      storageState: 'playwright/.auth/admin.json',
    });
    const page = await context.newPage();

    await use(page);

    await context.close();
  },
});

export { expect };

The test must not store adminPage in a module global or use it after its test completes. Fixture dependencies determine teardown order, so model resources as dependencies rather than relying on hook order.

If teardown needs the page to upload logs or make a final request, do that before closing its context. Keep teardown bounded because a stalled cleanup can trigger the runner timeout and cause additional closure errors.

Worker-scoped fixtures live across tests in one worker. They may own expensive services, but a mutable page is rarely a good worker-scoped shared fixture because test state leaks. Prefer a fresh context or page per test even when the browser process is worker-scoped.

The typing Playwright fixtures guide covers fixture types and scope design in more depth.

8. Register Popup and New-Page Waits Before the Trigger

A popup can open and close quickly. If the listener is registered after the click, the event can be missed or the page can already be gone when code starts using it.

Correct popup pattern:

const popupPromise = page.waitForEvent('popup');
await page.getByRole('link', { name: 'Open receipt' }).click();
const popup = await popupPromise;

await popup.waitForLoadState('domcontentloaded');
await expect(popup.getByRole('heading', { name: 'Receipt' })).toBeVisible();

When any page in the context can open the new tab, wait on the context:

const newPagePromise = context.waitForEvent('page');
await page.getByRole('button', { name: 'Open report' }).click();
const reportPage = await newPagePromise;
await reportPage.waitForLoadState('domcontentloaded');

Register first, trigger second, await the event promise third. This ordering avoids the race. If the application intentionally closes the popup after transferring data, assert the required content or message before closure, or wait for the close event when closure is the behavior under test.

Do not keep using the opener if the application closes or replaces it. Check page.isClosed() only as diagnostic or intentional branching, not as a polling workaround. The correct object depends on the application's window lifecycle.

9. Coordinate Downloads, Responses, and Navigation Without Races

The same register-before-trigger rule applies to downloads, responses, requests, and navigations that an action causes.

const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Export CSV' }).click();
const download = await downloadPromise;

const suggestedName = download.suggestedFilename();
expect(suggestedName).toMatch(/\.csv$/);

For a response:

const responsePromise = page.waitForResponse((response) =>
  response.url().endsWith('/api/profile') && response.request().method() === 'PUT',
);
await page.getByRole('button', { name: 'Save' }).click();
const response = await responsePromise;
expect(response.status()).toBe(200);

Avoid a broad unresolved wait that remains active until teardown. Give the predicate a precise URL and method, and await it within the test. If the click fails, handle the response promise carefully so it does not become a later unhandled rejection.

Most ordinary navigations do not require an explicit waitForNavigation pattern because Playwright actions and web-first assertions coordinate common cases, and waitForNavigation is discouraged due to inherent race concerns. Prefer waitForURL for a known destination or assert toHaveURL after the action.

await page.getByRole('link', { name: 'Dashboard' }).click();
await expect(page).toHaveURL(/\/dashboard$/);

The goal is to keep every event promise inside the same owned lifecycle as its page.

10. Remove Shared Globals from Parallel Tests

A module-level page or context shared across tests creates nondeterministic ownership. One test or hook can close, navigate, or replace it while another worker still uses it. Playwright workers run in separate processes, but shared external state and incorrectly initialized globals still cause collisions within files or custom infrastructure.

Incorrect design:

let sharedPage: import('@playwright/test').Page;

test.beforeAll(async ({ browser }) => {
  sharedPage = await browser.newPage();
});

test.afterAll(async () => {
  await sharedPage.close();
});

Prefer the built-in test-scoped page:

test('scenario one', async ({ page }) => {
  await page.goto('/one');
});

test('scenario two', async ({ page }) => {
  await page.goto('/two');
});

Fresh contexts provide clean cookies, local storage, permissions, and pages. This isolation is one of Playwright Test's core strengths. Do not trade it away for a small setup optimization.

If a suite genuinely needs serial shared browser state, document the dependency and use test.describe.configure({ mode: 'serial' }) sparingly. Serial mode is not a fix for accidental coupling. Prefer API-based state setup or reusable storage state so tests can remain isolated and parallel.

Run with --workers=1 as a diagnostic. If it passes, inspect ownership and shared application data, then restore normal worker count after the fix.

11. Close Manually Owned Resources in the Right Order

Standalone scripts that use the Playwright library own everything they launch. Keep actions inside a try block and close the browser once in finally after all dependent work completes.

import { chromium } from 'playwright';

const browser = await chromium.launch();

try {
  const context = await browser.newContext();

  try {
    const page = await context.newPage();
    await page.goto('https://example.com/');
    console.log(await page.title());
  } finally {
    await context.close();
  }
} finally {
  await browser.close();
}

Closing the context closes its pages, so an extra page close is usually unnecessary. If a page-specific cleanup must run, complete it before closing the context. Do not call browser.close() in several nested helpers. Give one owner final responsibility and make subordinate helpers return normally.

During shutdown, first stop background tasks and event producers, then await their completion, then close child resources, then the parent browser. This prevents callbacks from using resources during teardown.

A close call can itself race with another failure. Preserve the original error and avoid letting cleanup replace it. Use try and finally carefully, but do not catch and ignore every close error because it may reveal a genuine lifecycle defect. Log cleanup failures with context while keeping the primary test failure visible.

12. Distinguish Explicit Closure from Browser or Page Crash

If code search and lifecycle ownership look correct, investigate process loss. Listen for browser.on('disconnected') and page.on('crash'). A page crash indicates its renderer became unusable. A browser disconnect can result from explicit browser.close(), process termination, container eviction, or a browser crash.

Collect:

• Browser and Playwright versions from the locked environment.
• Browser stderr and runner logs.
• Operating system and container exit codes.
• Out-of-memory or eviction events.
• Worker count, shard count, memory, CPU, and shared-memory configuration.
• The URL and action before the crash, without sensitive data.
• Trace, screenshot, and video when they completed before process loss.

Resource pressure often appears only in CI or under parallel load. Reduce workers temporarily to confirm correlation, then size the runner, reduce application or test resource consumption, and inspect leaks. Do not leave the suite permanently serialized without understanding capacity.

A browser crash on one specific page can point to application content, a browser bug, or extreme renderer use. Create a minimal reproduction and test supported browser projects. Keep Playwright and its managed browsers aligned through the normal install process. The Playwright browser executable guide addresses provisioning failures before launch, which are separate from a process that closes after launch.

13. Interpret Timeouts, Retries, and Teardown Errors

A target-closed message can be secondary to an earlier test timeout. When the test exceeds its time budget, the runner begins cleanup. An operation still waiting on the page then reports closure. In the report, find the first timeout, assertion, or hook failure in chronological order.

Do not raise the global timeout only to avoid teardown. Determine why the operation did not finish. It may wait for an event registered too late, a locator that never matches, an unavailable application, or an unawaited callback. The Playwright timeout troubleshooting article provides a systematic timeout workflow.

Retries create fresh workers in some failure situations and can make logs appear to show multiple closures. Label logs with test.info().retry and worker index when correlating attempts. A passing retry does not prove the lifecycle is safe.

Hooks have timeouts too. A slow afterEach that uses a page while another cleanup closes its context can produce confusing output. Keep artifact collection within runner-supported tracing, screenshots, and attachments where possible. Make custom teardown small and dependency-aware.

When multiple errors are reported, rank them:

1. First application or assertion failure.
2. Test or hook timeout.
3. Lifecycle event or process exit.
4. Later operations reporting a closed target.

Fixing the earliest cause often removes the rest.

14. Prevent and Fix Playwright Target page context or browser has been closed Regressions

Adopt an ownership rule: the creator closes the resource, except runner-provided fixtures, which the runner closes. Every async task using a resource must complete within that owner's lifetime. Store no page or context in module globals.

Configure useful failure artifacts:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  use: {
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
});

Artifacts support diagnosis, but they do not replace lifecycle discipline. Review all manual close() calls, async event handlers, forEach(async ...) uses, and detached promises. Test under the normal worker count and a focused single-worker run to expose concurrency dependence.

After the repair, add an outcome assertion after the operation that previously raced. Run the test repeatedly in the affected project, then the containing suite. Confirm no unhandled rejection or lifecycle log appears after the test result. In CI, inspect resource graphs and process exits across a full parallel run.

The durable result is a clear owner, an awaited task graph, and teardown that begins only after dependent work ends.

Interview Questions and Answers

Q: What does Target page context or browser has been closed mean?

A Playwright operation tried to use a target whose page, parent context, browser, or protocol connection was already closed. The throwing action is often later than the actual lifecycle event, so I trace ownership and the first close, disconnect, crash, or teardown.

Q: Why can a missing await produce this error?

The test function can finish while the unawaited promise still uses the page. Playwright then tears down the test-scoped context, and the background task resumes against a closed target.

Q: Should a test call browser.close() on the browser fixture?

No. Playwright Test owns the browser fixture and coordinates its lifetime. A test should close only contexts or pages it explicitly created, and only after their dependent work ends.

Q: Why does forEach(async ...) cause lifecycle bugs?

forEach ignores the promises returned by its callbacks. The enclosing function does not wait, so callbacks can continue after teardown. I use for...of for sequence or Promise.all for intentional concurrency.

Q: How do you handle a popup safely?

I create the waitForEvent('popup') promise before the triggering action, await the action, then await the popup. I also observe whether the application intentionally closes it before assertions finish.

Q: How do you diagnose a browser crash in CI?

I collect disconnect and page-crash events, browser stderr, container or OS exit evidence, OOM events, worker count, versions, and failure artifacts. I compare single-worker and normal concurrency without treating serialization as the final fix.

Q: What is the correct manual cleanup order?

Stop and await background work first, complete page-dependent cleanup, close contexts, then close the browser once through its owner. Parent closure invalidates every child.

Q: Why can this message be secondary to a timeout?

When the runner times out, teardown closes fixtures while pending operations are still active. Those operations then report closed targets, so the first timeout or failed wait is the cause to investigate.

Common Mistakes

• Omitting await from a locator assertion, page action, or helper promise.
• Using forEach(async ...) and assuming callbacks complete before test end.
• Calling browser.close() on Playwright Test's built-in browser fixture.
• Storing a page or context in a module-level global.
• Sharing one mutable page across parallel tests for speed.
• Registering popup, download, or response waits after the triggering click.
• Starting timers or detached tasks that retain test-scoped objects.
• Closing a context before page-dependent teardown finishes.
• Treating retries or serial mode as proof that ownership is correct.
• Debugging only the final closed-target stack instead of the earliest failure.
• Ignoring browser disconnected, page crash, exit codes, and OOM evidence.
• Raising timeouts while leaving an unresolved event or missing await in place.

Conclusion

To fix playwright Target page context or browser has been closed, reconstruct the lifecycle. Identify who created the resource, who is allowed to close it, which tasks still depend on it, and which close, timeout, disconnect, or crash happened first. Await every dependent task and let Playwright Test manage its built-in fixtures.

Then isolate pages and contexts across parallel tests, register event waits before triggers, close manually owned resources from child to parent, and use process evidence for genuine crashes. A stable fix does more than remove the final error. It makes resource ownership and asynchronous completion explicit enough that teardown can never surprise an active test operation.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Fix Playwright Execution context was destroyed
• How to Fix Playwright locator resolved to hidden element
• How to Fix Playwright waiting for element to be visible enabled and stable
• How to Fix Playwright browserType.launch executable does not exist
• How to Fix Playwright element is not visible
• How to Fix Playwright element is outside of the viewport