Password dialogs in Chrome might prevent input events dispatched by chrome-devtools-mcp

Summary

After certain tab events, ALL CDP-injected input to that tab — click, fill, press_key — stops reaching the renderer, while the MCP tools keep returning success ("Successfully clicked on the element"). The result is silent false positives: an agent-driven test concludes "the app is broken / the button stalls" when in fact the input was never delivered.

Environment

• chrome-devtools-mcp via npx (current as of 2026-06), macOS (darwin 25.5), Chrome 149
• Dedicated profile via --userDataDir

Symptom detail

• take_snapshot works, uids are fresh, the target is a plain <button onClick={…}>.
• click on the button returns success — but a capture-phase probe registers zero DOM events:

  // via evaluate_script, before clicking:
  window.__probe = [];
  ['pointerdown','mousedown','mouseup','click'].forEach(t =>
    document.addEventListener(t, e => window.__probe.push(t), true));
  // → after the MCP click tool reports success, window.__probe is still []
  

• evaluate_script with element.click() works immediately (so the page, the handler, and the element are fine).
• Hit-testing exonerated: document.elementFromPoint(centerX, centerY) returns the target button.
• Mouse AND keyboard input are affected once the tab enters this state.

Triggers observed

The tab enters the dead-input state after:

1. Completing a sign-in step on a page (input worked for the credential fill + submit, then died mid-page with no navigation); subsequent clicks on the consent dialog of the same page never arrive.
2. Re-navigating an existing tab via navigate_page (dead immediately after).

A fresh new_page tab restores input delivery until a trigger recurs.

Repro sketch (any login→consent flow should do)

1. new_page → a login page; fill credentials (works), click submit (works).
2. Same-page consent/confirm dialog renders.
3. click the confirm button → tool reports success, page state unchanged, zero network, zero console, zero DOM events (probe above).
4. evaluate_script element.click() → flow completes instantly.

Possibly related

#1794 — the stacking "Allow remote debugging?" native popup. A native Chrome UI bubble stealing focus would explain exactly this signature (trusted/CDP input swallowed, JS-dispatched events unaffected). We could not visually confirm a bubble (headless-ish agent usage), but the save-password bubble was also on our suspect list.

Why this matters

Agent loops trust the tool result. "Successfully clicked" + no effect sent us debugging the application for a stall that didn't exist. If delivery can't be guaranteed, an error or warning from the click tool when the dispatch target tab has a native UI overlay / lost input focus would prevent the false positive.

Workaround we use

Capture-phase event probe before concluding anything from a no-op click; evaluate_script DOM clicks for post-login interactions; one fresh new_page per flow; verify outcomes out-of-band.

Start with the click, fill, and press_key tool entry points and trace how they dispatch input through Chrome DevTools Protocol. Reproduce the login-to-consent and navigate_page flows while checking the capture-phase probe and tool results. Done means the dead-input condition is understood and the tools no longer silently report successful delivery when input was swallowed, with a regression check for the reported triggers.