[Bug]: browser_resume hangs indefinitely when no subsequent breakpoint exists

[SebTardif]

System info

• Playwright Version: main (introduced in feat(cli): running with --debug=cli allows attaching and debugging over cli #39717)
• Operating System: all
• Browser: all
• Other info: MCP tools

Source code

• I provided exact source code that allows reproducing the issue locally.

Steps

1. Start Playwright with --debug=cli and connect an MCP client
2. A script pauses via page.pause() or requestPause()
3. Call browser_resume (no step or location params)
4. The script completes without hitting another page.pause()

Expected behavior

browser_resume should return once the debugger resumes execution.

Actual behavior

browser_resume hangs indefinitely. The handler unconditionally creates a promise waiting for the next pausedstatechanged event, but if execution completes without another breakpoint, pausedstatechanged never fires and the promise never resolves.

The hang is specific to a plain resume (no step or location). When step is set, it makes sense to wait for the next pause. When location is set, the handler sets a breakpoint, so a pause event is expected. A plain resume has no such expectation.

Use case

An MCP agent inspects the paused state (variables, DOM), then calls browser_resume to let the script finish. The agent does not know whether another page.pause() exists downstream. If the script completes normally, the agent is stuck.

This is the natural MCP workflow: pause, inspect, resume. The resume tool should not require the caller to predict whether the script will pause again.

[dgozman]

@SebTardif Unfortunately, this does not really explain the usecase. Why is MCP agent pausing the script? Where did the first page.pause() come from? Why does the agent need to let the script finish? If this is a debugging session, it's often better to stop the script rather than let it finish. Please be more specific.

[SebTardif]

@dgozman

Why is MCP agent pausing the script? Where did the first page.pause() come from?

From the developer's test code. The developer adds await page.pause() at a point they want to inspect, then runs with --debug=cli so an MCP client can examine the paused state.

Why does the agent need to let the script finish? If this is a debugging session, it's often better to stop the script rather than let it finish.

The test typically has assertions after the pause point. For example:

test('checkout flow', async ({ page }) => {
  await page.goto('/cart');
  await page.pause(); // inspect cart state here
  await page.click('#checkout');
  await expect(page.locator('.confirmation')).toBeVisible();
});

After inspecting the cart at the breakpoint, the agent calls browser_resume so the test can finish and report pass/fail. Stopping the script means the test runner never reports a result for the assertions that follow.

Stopping works when you only care about inspection. But when the developer wants to verify the rest of the test passes after a known state, resume-to-completion is the natural flow. The current browser_resume (plain, no step/location) assumes another breakpoint will always follow. When one doesn't, it hangs instead of returning.

[dgozman]

@SebTardif Thank you for the explanation. It seems like we can make browser_resume return when context closes, and it will fix your usecase. WDYT?

[SebTardif]

@dgozman Agreed, that is cleaner. I updated the PR to always wait for either the next pause or context close, instead of conditionally skipping the wait. This also handles unexpected context teardown.

#41293