Execution context was destroyed, most likely because of a navigation - Puppeteer

TL;DR

Why does the error happen?

• .click() fires but does not wait for navigation.
• If a navigation occurs, the execution context is destroyed.
• Puppeteer tries to execute evaluate() too soon, causing an error.

How do we fix it?

• Use await page.waitForNavigation() to ensure Puppeteer waits until the new page loads.
• If navigation isn’t certain, use await page.waitForSelector() instead.

Why Does This Happen?

If you've used Puppeteer to interact with a webpage, you've probably encountered this error at some stage:

Error: Execution context was destroyed, most likely because of a navigation.

This typically happens when Puppeteer tries to execute JavaScript on a page that is no longer available—usually because the page navigated away (and so the execution context for it is destroyed). Let’s break down why this occurs and how to fix it.

Consider the following Puppeteer script:

await page.click('a#navigate-away');
await page.evaluate(() => document.title);

Here’s what’s happening:

1. page.click() fires immediately, telling the browser to interact with the element.
2. If the clicked link triggers a page navigation, the old page starts unloading.
3. Before the new page fully loads, Puppeteer tries to execute evaluate().
4. But by then, the old execution context is gone, causing the error.

It's very easy to assume that the most trivial calls with Puppeteer are exempt from this issue. You'll find that the most 'harmless' calls can cause the most harmful failures.

Some 'harmless' examples which still require a stable execution context include:

• page.url()
• page.title()
• page.content()

Notice that these are merely read only actions. Just imagine that every time you call Puppeteer to do something, you’re making a fetch() request that could fail unpredictably. Just like you’d wrap a network request in try/catch to handle timeouts or errors, you should assume that any Puppeteer call—no matter how harmless it looks—might fail due to navigation, execution context loss, or frame detachment.

How to Fix It

Ensure Puppeteer waits for the navigation to complete before executing further JavaScript.

Solution 1 : Use waitForNavigation()

Instead of running .click() and immediately continuing, we can use Puppeteer's .waitForNavigation() method:

await Promise.all([
    page.waitForNavigation({ waitUntil: ['domcontentloaded', 'networkidle2'] }),
    page.click('a#navigate-away')
]);
 
await page.evaluate(() => document.title); // Now safe to execute

Check this out in the Puppeteer docs.

The page.waitForNavigation method takes (optional) options, which allow you to waitUntil certain life-cycle events occur on the page, add a timeout, or a signal to cancel the call. Take a look at the different lifecycle events here.

Solution 2: Wait for an Element Instead

If you're not sure whether navigation will happen or not, you can wait for an element unique to the new page to exist in the DOM:

await page.click('a#navigate-away');
await page.waitForSelector('h1'); // Ensures new content is loaded
await page.evaluate(() => document.title);

Check this out in the Puppeteer docs

This is more useful for sites that A/B test, where clicking or scrolling may cause a navigation sometimes but not every time. It's also handy for single page applications or modals that may change the DOM but not navigate away.

Taking Screenshots the easier and more reliable way

At Urlbox, we've already worked through the headaches you might be facing when trying to take screenshots of websites, HTML and PDF's.

We have a whole host of options that make it easy to get going, including waiting for elements on the page.

We also offer AI prompts, Cloud storage, No code integrations with Zapier, taking screenshots through proxies, and a range or other features that could save you time and hassle.

Sign up for our free trial and give our sandbox a try, or contact us directly, and we can help you find the answers you're looking for ✌️.