fix: skip frozen/discarded targets in page enumeration

[20syldev]

Problem

When Chrome freezes or discards background tabs (memory-saving behavior), browser.pages() can time out on Network.enable for those targets and abort the entire page enumeration — even though the rest of the browser and all active tabs are healthy.

Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.

This causes any MCP tool that needs page enumeration (list_pages, take_snapshot, navigation flows, etc.) to fail completely when the connected Chrome profile has been open long enough for background tabs to be frozen/discarded.

Root cause

browser.pages() iterates every page-type target and calls target.page() for each, which creates a Puppeteer CDP session and sends initialization commands including Network.enable. Frozen/discarded targets cannot respond to page-session CDP commands, so they time out — and the error propagates out of browser.pages(), killing the entire list.

Fix

Replace the single browser.pages() call in #getAllPages() with a per-target iteration over browser.targets(). Each call to target.page() is wrapped in its own try/catch so that one unresponsive background tab is logged and skipped instead of aborting the whole enumeration.

• page type targets are always included (existing behavior)
• background_page / webview types are included when experimentalIncludeAllPages is set (preserves existing opt-in behavior)
• The allTargets snapshot is reused for the extension-target loop below, so there is no extra browser.targets() call

Fixes #1230

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[OrKoN]

cc @nroscino

[OrKoN]

Please add a test demonstrating that it works with actual frozen tabs in the browser and not only in the mock. As I mentioned on #1230 (comment) I have troubles reproducing the issue. Do you have additional details for the manual reproduction?

[20syldev]

Please add a test demonstrating that it works with actual frozen tabs in the browser and not only in the mock. As I mentioned on #1230 (comment) I have troubles reproducing the issue. Do you have additional details for the manual reproduction?

How to reproduce

The issue requires a dead renderer — Page.setWebLifecycleState("frozen") via CDP is not enough because the renderer still responds to CDP commands. The actual scenario is a tab whose renderer process was killed (discarded by Chrome's memory saver or crashed).

Steps:

1. Launch Chrome with remote debugging:

   google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug

2. Open a few tabs, then navigate one to chrome://crash (kills the renderer)
3. Run this script:

   import { connect } from 'puppeteer';
   
   const browser = await connect({ browserURL: 'http://localhost:9222' });
   console.log('Connected, calling browser.pages()...');
   const pages = await browser.pages(); // hangs here for 180s
   console.log(pages.length);

4. browser.pages() → hangs indefinitely (180s protocolTimeout)

This only happens with puppeteer.connect(), not puppeteer.launch(), because launch auto-attaches to all targets and caches Page instances. On connect, target.page() has to initialize from scratch, sending Network.enable to a dead renderer that never responds.

Added test

The new integration test (should enumerate pages when a tab has a crashed renderer) reproduces exactly this:

• Launches Chrome, creates an active page and a crashed page (chrome://crash)
• Disconnects and reconnects via WebSocket
• Creates an McpContext (which calls #getAllPages() internally)
• Asserts it completes in under 20s and finds the active pages

$ NODE_TEST_REPORTER=spec npm test -- tests/McpContext.test.ts 2>&1 | grep -A2 "crashed renderer"

✔ should enumerate pages when a tab has a crashed renderer (10459.212304ms)

~10s = two #getAllPages() calls during init, each hitting the 5s per-target timeout on the crashed tab. Without the fix, this would be 360s+ (2 × 180s protocolTimeout).

[barretlee]

Is the enumeration here sufficient? type: What are the categories in total?

[20syldev]

The CDP target types are: page, background_page, service_worker, webview, worker, shared_worker, browser, and other.

Here only page is enumerated by default (same as what browser.pages() did before), and background_page + webview are added when experimentalIncludeAllPages is on — that's the pre-existing opt-in. The rest (service_worker, worker, etc.) aren't navigable pages so target.page() wouldn't return anything useful for them.