[Bug]: (Debugger.enable): Script execution is prohibited

[adamraine]

Minimal, reproducible example

import * as puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  headless: false,
});
const page = await browser.newPage();
const session = await page.target().createCDPSession();

const timeout = 30000;
page.setDefaultTimeout(timeout);

await page.setViewport({
  width: 1903,
  height: 963,
});
await page.goto("http://13.48.26.180/");

{
  const promises = [];
  const startWaitingForEvents = () => {
    promises.push(page.waitForNavigation());
  };
  await puppeteer.Locator.race([
    page.locator("::-p-aria(ABOUT)"),
    page.locator("li:nth-of-type(2) > a"),
    page.locator(
      '::-p-xpath(//*[@id=\\"navbarSupportedContent\\"]/ul/li[2]/a)'
    ),
    page.locator(":scope >>> li:nth-of-type(2) > a"),
  ])
    .setTimeout(timeout)
    .on("action", () => startWaitingForEvents())
    .click({
      offset: {
        x: 46.546875,
        y: 21.5,
      },
    });
  await Promise.all(promises);
}

// This command fails
await session.send('Debugger.enable');

await browser.close();

Error string

ProtocolError: Protocol error (Debugger.enable): Script execution is prohibited

Bug behavior

• Flaky
• PDF

Background

Lighthouse issue: GoogleChrome/lighthouse#15525

The original script looks like it was made by the replay library, but I was able to minify the script and repro without much replay stuff.

Expectation

No errors are thrown

Reality

Error is thrown on the Debugger.enable command

Puppeteer configuration file (if used)

No response

Puppeteer version

21.3.8

Node version

18.17.0

Package manager

yarn

Package manager version

1.22.19

Operating system

macOS

[github-actions]

This issue was not reproducible. Please check that your example runs locally and the following:

• Ensure the script does not rely on dependencies outside of puppeteer and puppeteer-core.
• Ensure the error string is just the error message.

  • Bad:

    Error: something went wrong
      at Object.<anonymous> (/Users/username/repository/script.js:2:1)
      at Module._compile (node:internal/modules/cjs/loader:1159:14)
      at Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
      at Module.load (node:internal/modules/cjs/loader:1037:32)
      at Module._load (node:internal/modules/cjs/loader:878:12)
      at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
      at node:internal/main/run_main_module:23:47

  • Good: Error: something went wrong.

• Ensure your configuration file (if applicable) is valid.
• If the issue is flaky (does not reproduce all the time), make sure 'Flaky' is checked.
• If the issue is not expected to error, make sure to write 'no error'.

Once the above checks are satisfied, please edit your issue with the changes and we will
try to reproduce the bug again.

---

Analyzer run

[OrKoN]

Shorter repro:

import * as puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  headless: false,
});
const page = await browser.newPage();
const session = await page.target().createCDPSession();

await page.setViewport({
  width: 1903,
  height: 963,
});
await page.goto("http://13.48.26.180/");

const result = await page.waitForSelector('li:nth-of-type(2) > a');

await result.click()

// This command fails
await session.send('Debugger.enable');

await browser.close();

[OrKoN]

The bug is in Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=1492053

[OrKoN]

So disabling ProcessPerSiteUpToMainFrameThreshold would fix the issue but ultimately the session is probably wrong here. The page is bfcached and the session is created to the initial target. That target gets put into the bfcache after navigation and while Debugger.enable might work for it, it is probably not what you want.

[adamraine]

Just to clarify, is there something that needs to change in the script for this to work or is puppeteer using an invalid session somehow?

[OrKoN]

@adamraine The main reason for the problem is that the heuristics used by ProcessPerSiteUpToMainFrameThreshold to disable Debugger get confused (and the fact that the feature disabled by default somehow got enabled in CfT builds). I think Puppeteer is using the right session here but I am not sure if bfcache implementation in Chrome re-targets the session correctly (I hope the crbug I filed clarifies this). At the same time I believe the same/similar issue might occur during a pre-rendering navigation, and in that case the client code needs to be changed. In this case, I think it would be more robust to create the session after the navigation (and I think this works around the problem too). In general, I think any code that deals with CDP sessions directly should account for the mparch changes in Chrome.

[adamraine]

In this instance, creating the session after the page nav doesn't fix the issue for me. I modified the script to look like this:

import * as puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  headless: false,
});
const page = await browser.newPage();

await page.setViewport({
  width: 1903,
  height: 963,
});
await page.goto("http://13.48.26.180/");

const result = await page.waitForSelector('li:nth-of-type(2) > a');

const navPromise = page.waitForNavigation({
  waitUntil: ['load', 'networkidle0']
});
await result.click()
await navPromise;

const session = await page.target().createCDPSession();

// This command fails
await session.send('Debugger.enable');

await browser.close();

[OrKoN]

@adamraine interesting, I am pretty sure I saw a similar script pass for me but I cannot reproduce anymore. Maybe there are some situations where the page is evicted from bfcache? 🤔

[OrKoN]

The test site is not available anymore so I am closing the issue as it is not reproducible. The feature ProcessPerSiteUpToMainFrameThreshold is disabled by default now.