Repository navigation
[Bug]: browser_resume hangs indefinitely when no subsequent breakpoint exists #41304
Description
Activity
Sebastien Tardif (@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.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=cliso 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_resumeso 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, nostep/location) assumes another breakpoint will always follow. When one doesn't, it hangs instead of returning.Sebastien Tardif (@SebTardif) Thank you for the explanation. It seems like we can make
browser_resumereturn when context closes, and it will fix your usecase. WDYT?Dmitry Gozman (@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.
System info
Source code
Steps
--debug=cliand connect an MCP clientpage.pause()orrequestPause()browser_resume(nosteporlocationparams)page.pause()Expected behavior
browser_resumeshould return once the debugger resumes execution.Actual behavior
browser_resumehangs indefinitely. The handler unconditionally creates a promise waiting for the nextpausedstatechangedevent, but if execution completes without another breakpoint,pausedstatechangednever fires and the promise never resolves.The hang is specific to a plain resume (no
steporlocation). Whenstepis set, it makes sense to wait for the next pause. Whenlocationis 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_resumeto let the script finish. The agent does not know whether anotherpage.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.