Bug: dialog blocks snapshot

[route250]

Description

When using Playwright MCP, if a browser_click action triggers a native browser dialog (alert, confirm, prompt), the call currently hangs until the dialog is handled. There is no way for the client to know that a dialog appeared, nor to retrieve its type or message for conditional handling.

Proposal

• When browser_click triggers a dialog, the response should immediately indicate:
  • That a dialog appeared
  • The dialog type (alert, confirm, prompt)
  • The dialog message text
• This would allow clients to implement conditional logic based on the dialog content, and avoid indefinite hangs.

Steps to Reproduce

1. Use browser_click to click a button that triggers a native dialog.
2. Observe that the call hangs and no dialog information is returned.

Expected Behavior

• browser_click should return a response indicating a dialog appeared, with its type and message, instead of hanging.

Actual Behavior

• browser_click hangs until the dialog is handled, and no dialog information is available to the client.

Environment

• Playwright MCP version:0.0.29

Additional Context

This enhancement would make it possible to automate workflows that require conditional dialog handling, and improve robustness of MCP-based browser automation.

[Skn0tt]

We have support for this with the browser_handle_dialog tool. If it doesn't work for you, that sounds like a bug. Could you elaborate on the behaviour you're seeing, ideally with screenshots attached, and provide us with a prompt we can run to reproduce the bug you're seeing?

[route250]

I wasn’t familiar with browser_handle_dialog, so I restructured my test code to adopt it. The test script is mcp_client_test.py.

The actual application I’m trying to automate is a React-based web app. Since it’s too complex for isolated testing, I created a simplified version of the server-side code named uitest_serverA.py. When I run the test with this setup, it hangs after clicking the “Login” button.

To narrow things down further, I created an even simpler version called uitest_serverB.py. With this one, the click action does not hang — even if I remove browser_handle_dialog, the test runs through without blocking.

If this issue can be resolved, it would be really great. What do you think?

mcp_client_test.py.gz

uitest_serverA.py.gz

uitest_serverB.py.gz

We have support for this with the browser_handle_dialog tool. If it doesn't work for you, that sounds like a bug. Could you elaborate on the behaviour you're seeing, ideally with screenshots attached, and provide us with a prompt we can run to reproduce the bug you're seeing?

[Skn0tt]

You are using the tool the wrong way. Playwright MCP is meant to be used in conjunction with an agentic loop like Copilot or Claude Code. You should use Playwright Python directly: https://playwright.dev/python/

[route250]

Of course, my goal is to use playwright-mcp as a tool for LLMs. I’m aiming to perform automated testing of web applications using AI, and during that verification process, I encountered this issue while investigating the cause of a hang-up.

The Python-based test code is only used to reliably reproduce the issue. Since LLM behavior can vary, I’m using Python to ensure consistent and repeatable execution.

In any case, is it correct to understand that this issue requires exploring alternative solutions?

[Skn0tt]

I see, sorry for closing too early! I can reproduce the hang you're mentioning, that looks wrong. Investigating.

[Skn0tt]

I was able to narrow the repro down to this:

# /// script
# dependencies = [
#   "mcp"
# ]
# ///

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import base64

html = """
<form>
    <button id="button" type="submit">Login</button>
</form>
<script>
document.getElementById('button').addEventListener('click', async function(event) {
    event.preventDefault();
    setTimeout(() => {
        alert('invalid user or password');
    }, 1000); // Simulate delay for invalid login
});
</script>
"""

async def main():
    async with stdio_client(StdioServerParameters(command="npx", args=["@playwright/mcp@latest"])) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            response = await session.call_tool("browser_navigate", { "url": "data:text/html;base64," + base64.b64encode(html.encode()).decode() })
            response = await session.call_tool("browser_click", { "element": "Login", "ref": "e3" })

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

uv run repro.py

haven't been able to transform it into a repro in our codebase yet, though.

[Skn0tt]

Here's a repro for our codebase:

test.fail('alert dialog repro', { annotation: { type: 'issue', description: 'https://github.com/microsoft/playwright-mcp/issues/595' } }, async ({ client, server }) => {
  server.setContent('/', `
    <form>
        <button id="button" type="submit">Login</button>
    </form>
    <script>
    document.getElementById('button').addEventListener('click', async function(event) {
        event.preventDefault();
        setTimeout(() => {
            alert('invalid user or password');
        }, 1000);
    });
    </script>
  `, 'text/html');
  expect(await client.callTool({
    name: 'browser_navigate',
    arguments: { url: server.PREFIX },
  })).toContainTextContent('- button "Login" [ref=e3]');
  expect(await client.callTool({
    name: 'browser_click',
    arguments: {
      element: 'Login',
      ref: 'e3',
    },
  })).toHaveTextContent(`- Ran Playwright code:
\`\`\`js
// Click Login
await page.getByRole('button', { name: 'Login' }).click();
\`\`\`

### Modal state
- ["alert" dialog with message "password is incorrect"]: can be handled by the "browser_handle_dialog" tool`);
});

The problem is that the alert() call blocks the browser event loop at the time where Playwright MCP tries capturing a snapshot, but without the snapshot the alert can't be dismissed. We guard against that with the _raceAgainstModalDialogs function, and we probably need to extend that towards the snapshot taking.