How to Fix Playwright Execution context was destroyed

TL;DR

To fix Playwright Execution context was destroyed, stop evaluating or using handles across a document lifecycle change. Await the action that triggers navigation, wait for the expected URL or destination locator, and only then read the new page. Replace ElementHandle and JSHandle reuse with locators, serialize any data before leaving the old document, and remove concurrent or unawaited work that can navigate, reload, close, or replace a frame.

Key Takeaways

• A full document navigation, reload, frame replacement, or page closure destroys the JavaScript context where evaluate code and handles live.
• Give every navigation one clear owner and wait for the resulting URL or user-visible destination state before reading the new document.
• Keep browser-context evaluation short, return serializable values, and never carry ElementHandle or JSHandle objects across navigation.
• Prefer locators and web-first assertions because they resolve against the current document instead of preserving stale DOM nodes.
• Remove unawaited actions and unsafe Promise.all groups that allow navigation to overlap unrelated evaluation.
• Treat iframe replacement, redirects, pop-ups, downloads, and teardown as distinct lifecycle events with explicit waits.
• Use traces, frame and navigation logs, console evidence, and focused repetition to locate the first unexpected lifecycle change.

To fix playwright Execution context was destroyed, identify which navigation, reload, frame replacement, or page closure invalidated the JavaScript world while your code was still using it. Then place a clear synchronization boundary around that lifecycle change and avoid carrying browser-side handles from the old document into the new one.

This error is not fixed reliably by adding a delay. It is a race between work executing in one document and an event that removes that document. The durable solution uses locators, web-first assertions, page.waitForURL(), page or frame events, and disciplined async control. This guide explains the browser model, common patterns, runnable repairs, and an interview-ready diagnostic approach.

TL;DR

The first task is to find the event that destroyed the context, not the line that happened to observe the destruction.

1. What an Execution Context Is

Browser JavaScript runs inside an execution context associated with a document or isolated world. When Playwright calls page.evaluate(), locator.evaluate(), or creates a JSHandle, part of that work lives in the browser process and references the current document's JavaScript environment. A full navigation commits a new document and destroys the old environment.

The main frame can lose its context during page.goto(), link or form navigation, reload, server redirect, location assignment, or another page action that commits a document. A child frame has its own lifecycle and loses context when its source navigates or the iframe is replaced. Closing the page or browser context also invalidates browser-side work.

A same-document navigation, such as a hash update or many client-side router transitions, normally keeps the document and execution context. However, an application can appear to perform client routing and then trigger a full reload because of authentication, error recovery, or server configuration. Diagnose the actual event rather than assuming the framework behavior.

Locators are safer because they describe how to find an element when an operation runs. ElementHandle and JSHandle refer to particular objects in one context. Current Playwright guidance discourages handle-driven element interaction for dynamic pages.

The error line often points to a read or assertion after the real trigger. Build a timeline: last stable URL, action, navigation commit, frame change, evaluation, and teardown.

2. Root causes when you fix playwright Execution context was destroyed

Most failures belong to a small number of lifecycle races. Use the trace and stack to classify them.

A timeout and a destroyed context can be related. The test may start a navigation race, retry work, and eventually exhaust its budget. Fix the lifecycle ordering first. The Playwright timeout troubleshooting guide covers the remaining budget issue.

3. Identify the Navigation Boundary

Every navigation should have an understandable owner: a test action, application timer, redirect, route guard, form submission, reload button, or recovery script. Record the URL before the failing step and observe main-frame navigation events during diagnosis.

page.on('framenavigated', frame => {
  if (frame === page.mainFrame()) {
    console.log('main frame navigated:', frame.url());
  }
});

Use this temporary logging with a trace. It proves when commits occur but does not make the test wait. Remove or narrow it after diagnosis to avoid noisy output or accidental logging of sensitive query parameters.

In the trace, inspect actions and snapshots around the first URL change. A click may trigger a navigation even if the test author expected an in-page update. A failed authorization request can send the page to login. A button can submit a form because its HTML type defaults to submit. A framework error boundary can reload the entire application.

Name the expected destination precisely. A URL pattern, page heading, account identifier, or domain status is better than a generic load state. Modern pages continue background work after load, so "page loaded" is application-specific.

If the navigation is unexpected, repair the application or prior test state. Adding a wait around an unintended redirect merely makes the wrong journey deterministic.

4. Use waitForURL and Destination Assertions

For an action that causes a known navigation, await the action, wait for the expected URL, and assert a stable destination element. Locator actions already coordinate with navigations they initiate, while waitForURL() states which destination the test requires.

await page.getByRole('button', { name: 'Sign in' }).click();
await page.waitForURL('**/dashboard');
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

If a fast transition can occur independently of the action or you need to establish the observer first, create the wait promise before triggering the event, then await it:

const dashboardPromise = page.waitForURL('**/dashboard');
await page.getByRole('button', { name: 'Sign in' }).click();
await dashboardPromise;
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

Do not return to the older waitForNavigation() pattern. Current Playwright guidance recommends waitForURL() because generic navigation waits are inherently racy and often underspecified. Avoid waitForLoadState('networkidle') as a universal ready signal. Polling, analytics, and web sockets can make network idleness unrelated to user readiness.

For navigation without a predictable URL, assert the destination UI or wait for a specific response only when that response is the actual contract. The Playwright auto-waiting guide explains how actions and assertions divide synchronization responsibilities.

5. Keep Evaluation on One Side of Navigation

page.evaluate() is appropriate for browser-only information or APIs, but the callback must finish in the document where it started. Do not launch an evaluation, navigate, and await its result afterward.

Racy pattern:

const statePromise = page.evaluate(async () => {
  await new Promise(resolve => setTimeout(resolve, 500));
  return document.title;
});
await page.getByRole('link', { name: 'Next' }).click();
console.log(await statePromise);

Safe pattern when old-document data is required:

const previousTitle = await page.evaluate(() => document.title);
await page.getByRole('link', { name: 'Next' }).click();
await page.waitForURL('**/next');
console.log(previousTitle);

Safe pattern when new-document data is required:

await page.getByRole('link', { name: 'Next' }).click();
await page.waitForURL('**/next');
await expect(page.getByRole('heading', { name: 'Next step' })).toBeVisible();
const currentTitle = await page.title();
console.log(currentTitle);

Return serializable data from evaluate instead of a handle when the value must survive navigation. Keep callbacks short and free of test-runner objects. Variables captured by the Node function are not automatically available in the browser context, so pass explicit serializable arguments.

Do not move ordinary text, attribute, or state checks into evaluate. Locator assertions such as toHaveText(), toHaveAttribute(), toBeChecked(), and toBeVisible() retry safely against the current DOM and produce better diagnostic output.

6. Replace Stale ElementHandle and JSHandle Usage

A handle points to one browser object. Navigation destroys the context that owns it, and many framework re-renders detach the node even without navigation. Caching handles in page objects or fixtures creates hidden lifetime coupling.

Fragile code:

const button = await page.$('button[type=submit]');
await button?.click();
await page.waitForURL('**/complete');
await button?.getAttribute('disabled');

Locator-based code:

const submit = page.getByRole('button', { name: 'Submit order' });
await submit.click();
await page.waitForURL('**/complete');
await expect(page.getByRole('heading', { name: 'Order complete' })).toBeVisible();

The final assertion targets the destination document instead of asking an old button for state after it no longer exists.

Page objects should store locators, not resolved nodes. A locator can be created before navigation and used later if its selector logically applies to the new page, because it resolves at action time. Still, prefer destination-specific locators so the page model communicates lifecycle.

If a JSHandle is genuinely needed for a focused browser API test, keep its use within one known document and dispose it when finished. Never put browser handles into cross-test global state. For values needed later, evaluate and serialize only the necessary data before navigation.

7. Remove Missing Awaits and Unsafe Promise Concurrency

Playwright actions, assertions, navigation waits, and most data reads return promises. A missing await lets the test proceed while page state is still changing. The later operation may evaluate in a context that the earlier action destroys.

Incorrect:

page.getByRole('button', { name: 'Continue' }).click();
expect(page.getByRole('heading', { name: 'Review' })).toBeVisible();
const total = await page.getByTestId('total').textContent();

Correct:

await page.getByRole('button', { name: 'Continue' }).click();
await expect(page.getByRole('heading', { name: 'Review' })).toBeVisible();
const total = await page.getByTestId('total').textContent();

Enable a TypeScript-aware lint rule such as @typescript-eslint/no-floating-promises so missing awaits fail code review or CI. Also return promises from custom helpers and await the helper itself.

Do not use Promise.all() to make ordered interactions on one page look faster. Two clicks, a click plus a DOM read, or a navigation plus evaluation may compete for one mutable browser state. Concurrency is suitable for independent setup requests or for pairing an event wait that must be armed before its trigger. Keep the dependencies explicit.

Array forEach also does not await async callbacks. Use for...of for ordered page operations. If parallel API setup is safe, run it outside the user journey and give each task isolated data.

8. Handle Redirect Chains and Authentication Correctly

Authentication can involve several document commits: application to identity provider, callback, token processing, and application destination. Reading page DOM during an intermediate redirect creates context races. Wait for the final expected URL and a user-specific destination state.

await page.getByRole('button', { name: 'Continue with SSO' }).click();
await page.waitForURL(url =>
  url.origin === 'https://app.example.test' && url.pathname === '/dashboard'
);
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();

The URL above is illustrative. Use the approved environment's origin and avoid logging tokens or authorization codes. A predicate can validate origin and path without matching sensitive query strings.

For most non-login scenarios, create authenticated storage state in a setup project and start tests at the intended page. This reduces repeated redirect complexity while keeping dedicated authentication tests for the full flow. Do not copy expired storage state or share mutable accounts across parallel workers.

If login unexpectedly loops, inspect cookies, base URL, callback configuration, clock, and failed requests. The correct fix is not to catch and retry destroyed-context errors indefinitely. Repeated commits indicate that the session or routing contract is broken.

9. Distinguish Navigation, Pop-Up, and Download Lifecycles

A link may navigate the current page, open a new page, create a popup, or start a download. Tests become racy when they assume the wrong lifecycle. Capture the specific event before the triggering action.

For a new page:

const newPagePromise = page.context().waitForEvent('page');
await page.getByRole('link', { name: 'Open invoice' }).click();
const invoicePage = await newPagePromise;
await invoicePage.waitForLoadState('domcontentloaded');
await expect(invoicePage.getByRole('heading', { name: 'Invoice' })).toBeVisible();

For a popup tied to one page, page.waitForEvent('popup') is also appropriate. For a download:

const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Export CSV' }).click();
const download = await downloadPromise;
expect(download.suggestedFilename()).toMatch(new RegExp('[.]csv

Do not evaluate the original document while its trigger is still navigating or closing. Work within the returned `Page` or `Download` object. If clicking a link replaces the page instead of opening a popup due to a browser or product change, the event wait will expose that mismatch clearly.

## 10. Survive Dynamic Iframe Replacement

Payment widgets, editors, consent managers, and embedded reports often replace their iframe as they initialize or change state. A cached `Frame`, `ElementHandle`, or evaluation started in the old child document can fail when that frame detaches.

Use a frame locator that resolves the current frame and assert an inner state:

```ts
const payment = page.frameLocator('iframe[title="Secure payment"]');
await payment.getByLabel('Card number').fill('4242 4242 4242 4242');
await payment.getByRole('button', { name: 'Pay' }).click();
await expect(page.getByRole('heading', { name: 'Payment complete' })).toBeVisible();

If the iframe itself changes title, URL, or count during a provider flow, locate its stable owner and review the provider's documented public contract. Avoid selecting frames by numeric index. Ads, analytics, and experiments can reorder them.

During diagnosis, listen for frame attachment, navigation, and detachment and correlate those events with the trace. Remove broad logs afterward. If the product removes an iframe while a user operation is incomplete, the issue may belong to integration code rather than the test.

A frame can navigate without the main page URL changing. Waiting only on page.waitForURL() will not describe that child lifecycle. Prefer a user-visible locator inside the current frame or an outer application outcome.

11. Use a Complete Navigation-Safe Test Pattern

This runnable test intercepts two fictional application documents, performs a real link navigation, waits for the destination URL, and asserts the new document without carrying old handles:

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

test('moves from review to confirmation safely', async ({ page }) => {
  await page.route('https://app.example.test/**', async route => {
    const path = new URL(route.request().url()).pathname;
    if (path === '/review') {
      await route.fulfill({
        contentType: 'text/html',
        body: '<h1>Review order</h1><a href="/confirmation">Confirm order</a>',
      });
      return;
    }
    await route.fulfill({
      contentType: 'text/html',
      body: '<h1>Order confirmed</h1><p>Reference QA-2026</p>',
    });
  });

  await page.goto('https://app.example.test/review');
  await expect(page.getByRole('heading', { name: 'Review order' })).toBeVisible();

  await page.getByRole('link', { name: 'Confirm order' }).click();
  await page.waitForURL('**/confirmation');
  await expect(page.getByRole('heading', { name: 'Order confirmed' })).toBeVisible();
  await expect(page.getByText('Reference QA-2026')).toBeVisible();
});

The route handler fulfills documents without an external server, so the example can run in a Playwright Test project. The test awaits each phase and uses destination locators. It does not evaluate the old page after navigation.

In a real application, let application responses proceed normally. Use route fulfillment only where network mocking is part of the test design, not as a blanket way to remove genuine integration risk.

12. Prevent Premature Page Closure and Teardown Races

A page can lose its context because test code or fixture teardown closes it, not because the application navigates. This happens when a helper starts async browser work without returning its promise, a callback continues after the test ends, or a shared page is closed by another test.

Keep page ownership simple. Use the isolated page fixture for each Playwright Test case. Do not share one mutable Page across parallel tests. Custom fixtures must await setup, yield ownership with use, and await cleanup only after the consumer completes.

Avoid timers and detached promises that reference the page:

async function verifyAccount(page: Page): Promise<void> {
  await expect(page.getByRole('heading', { name: 'Account' })).toBeVisible();
}

test('shows the account', async ({ page }) => {
  await page.goto('/account');
  await verifyAccount(page);
});

Import Page from @playwright/test in the real file. The helper returns a promise and the test awaits it.

If a failure occurs during teardown, inspect whether the original test already failed or timed out. Teardown errors can be secondary. Preserve the first error, trace, and fixture steps. Closing browser contexts manually is usually unnecessary when Playwright Test owns them. If your code creates a separate context, close it in a finally block after all work that uses it has settled.

13. Debug and verify the fix playwright Execution context was destroyed workflow

Capture trace on first retry and screenshots on failure:

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

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

Correlate the first rejected API call with navigation, frame, popup, download, console, and network events. Check whether the URL changed intentionally, an iframe detached, the page closed, or an unawaited action was still running. The first context loss matters more than later cascaded errors.

Run the focused test repeatedly and under the original worker count. Timing-sensitive lifecycle races can disappear in a headed debugger. Use trace snapshots and event timestamps instead of adding a delay. The flaky test root-cause guide gives a broader evidence workflow.

Prevent recurrence with TypeScript, no-floating-promise linting, locator-based page objects, small helpers that return their promises, and code review rules against handles crossing navigation. Make navigation destinations explicit in tests.

A verified fix has one owner for each lifecycle change, no evaluation or handle spanning documents, and a stable user-visible assertion after the boundary. Remove temporary event logging and any catch-and-retry loop that could hide unexpected reloads.

Interview Questions and Answers

Q: What causes an execution context to be destroyed in Playwright?

A full document navigation, reload, frame navigation or replacement, page closure, or browser-context closure removes the JavaScript environment where evaluation and handles live. The error appears when pending or later work still references that environment.

Q: Why do locators help prevent this failure?

Locators store a query and resolve it against the current DOM when used. ElementHandle and JSHandle objects refer to specific objects in one context and become invalid when that context is destroyed.

Q: How should a test synchronize a navigation?

Await the user action, wait for the expected URL with waitForURL() when relevant, and assert a stable destination element. If the observer must be active first, create the wait promise before the trigger and await it afterward.

Q: Why is a fixed timeout not a real fix?

The problem is lifecycle ordering, not simply speed. A longer delay can change which operation loses the race but cannot preserve a context after its document is removed.

Q: How does Promise.all create context races?

It can run dependent operations on the same page concurrently, such as navigation and evaluation. I reserve it for independent work or a deliberately pre-armed event wait paired with its trigger.

Q: How do redirects affect page evaluation?

Each full redirect can commit a new document and destroy the previous context. I wait for the final trusted URL and destination state before reading DOM or browser data.

Q: How do you handle a dynamically replaced iframe?

I use frameLocator() and a stable frame owner, then wait on an inner or outer user-visible outcome. I do not preserve a frame or element handle across widget reinitialization.

Q: What evidence would you inspect in CI?

I inspect the trace, URLs, frame lifecycle, page close events, console errors, failed requests, and the first rejected call. I also check missing awaits, detached helpers, test timeout, and shared-page ownership.

Common Mistakes

• Adding waitForTimeout() and assuming the old execution context will survive longer.
• Starting page.evaluate() and navigating before awaiting its result.
• Caching ElementHandle or JSHandle objects in page objects across navigation.
• Omitting await on Playwright actions, assertions, or custom helpers.
• Running dependent interactions concurrently with Promise.all().
• Using deprecated generic navigation waits instead of a precise expected URL or destination state.
• Reading DOM during intermediate authentication redirects.
• Treating iframe navigation as if it always changed the main page URL.
• Continuing to use the opener page when the action created a popup or new page.
• Closing a page manually while detached helper work still references it.
• Catching and retrying destroyed-context errors without identifying an unexpected reload loop.
• Logging sensitive callback URLs or full page content during diagnosis.

Conclusion

To fix playwright Execution context was destroyed, make document and frame lifecycles explicit. Complete old-document work before navigation, await the trigger, wait for the intended destination, and assert new-document state through locators. Serialize values that must survive and discard handles tied to the old context.

Then remove concurrency and teardown races, verify redirects, frames, pop-ups, and CI timing, and preserve trace evidence for future failures. The goal is not to suppress the error. It is to make every lifecycle transition owned, observable, and deterministic.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Fix Playwright locator resolved to hidden element
• How to Fix Playwright Target page context or browser has been closed
• How to Fix Playwright waiting for element to be visible enabled and stable
• How to Add parallel execution to a framework (2026)
• How to Fix Playwright browserType.launch executable does not exist
• How to Fix Playwright element is not visible