Injected input (click/fill/press_key) silently stops reaching a tab; tools still report success

[perki]

---

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.

[zyzyzyryxy]

Hello, thank you for your report. Can you please provide any publicly accessible site address where the issue reproduces?

[perki]

Yes — the site where we hit it: https://demo-account.datasafe.dev (our public demo/test platform — feel free to hammer it; the account below is disposable).

Self-service repro (each flow URL is single-use, so mint fresh ones):

curl -s -X POST https://demo.datasafe.dev/reg/access \
  -H 'Content-Type: application/json' \
  -d '{"requestingAppId":"repro-issue-2199","requestedPermissions":[{"streamId":"diary","level":"read","defaultName":"Diary"}],"languageCode":"en"}' \
  | jq -r .authUrl

1. new_page → the printed authUrl (renders a sign-in form).
2. fill username tauth260611120035, password TestAuth260611120035! (throwaway test account), click Sign In.
3. A same-page consent panel renders with Accept / Reject.
4. click Accept.

When the bug bites, step 4 (sometimes already step 2) reports success while a capture-phase probe (document.addEventListener('click', …, true) installed via evaluate_script) records zero events, and evaluate_script element.click() completes the flow instantly.

Honest caveat on determinism: it does not reproduce on every run. In a fresh MCP session today the same flow completed normally (probe saw all pointerdown/mousedown/mouseup/click). We observed the dead-input state in long-lived sessions (hours, many tabs/navigations) — once a tab entered the state, all injected input (mouse + keyboard) to that tab was gone until a fresh new_page, while evaluate_script kept working. The two events that preceded it for us: completing the sign-in step (same-page re-render, no navigation), and re-navigating an existing tab via navigate_page. That intermittency is part of why #1794 (stacking native "Allow remote debugging?" popups) looks plausible from the outside — a bubble accumulating over a session's lifetime would match.

Happy to run further instrumented repros on our side (we can add any logging you'd like via evaluate_script) or to try a candidate fix/flag.

[zyzyzyryxy]

Are you encountering the error in headless or headful? Would it be possible to record a video of the automated browser window when the bug triggers for you? This would help identify native popups that block the interaction (it could be password managers, "Allow remote debugging?" you already mentioned or something else)

[perki]

Headful — macOS (darwin 25.5), real Chrome 149 window, launched by chrome-devtools-mcp via npx chrome-devtools-mcp --userDataDir /tmp/chrome-mcp-macro. No --headless. The profile is dedicated and clean — lives in /tmp (periodically wiped), no extensions, no third-party password manager. Which means Chrome's built-in save-password bubble would re-prompt after every login on this profile (no persisted "never" choice) — and our trigger #1 was exactly "input died right after a credentials submit". The timing fits your password-manager suspicion.

Video: the state is intermittent, so we can't film on demand — but two things we'll do:

1. Tripwire: our automation already detects the dead state (capture-phase probe sees zero events after a reported-success click). On the next occurrence we'll immediately capture the OS-level window via macOS screencapture -l <windowId> (CDP screenshots only render page content, so a native bubble would be invisible in them — OS capture includes native UI) and attach it here, plus a screen recording if the state persists long enough.
2. Differential experiment: we'll run the next few days of sessions with the built-in password manager prompt disabled on that profile (credentials_enable_service: false in the profile prefs). If the dead-input state never recurs with the bubble suppressed, that's a strong confirmation of the native-popup theory; if it recurs anyway, we've eliminated it. We'll report either way.

One more data point from our logs: the second trigger we saw (navigate_page re-navigation of an existing tab → input dead immediately) happened in the same long-lived session that had earlier done several logins — consistent with an already-present stacked bubble rather than re-navigation being a cause by itself.

[zyzyzyryxy]

I scripted the repro using cd4a CLI accessing the page you provided, 50 iterations later the error does not reproduce.
One thing I noticed there's no consent page, pressing login navigates straight to the "All set" page - inconsistent with your description., however should not affect reproduction.

repro_stress_test.sh

[zyzyzyryxy]

Only noticed your last response after posting my comment, my script used default session, it most probably has already "don't store passwords" selected for all sites, so this further confirms that hypothesis. Waiting for your confirmation from the experiment!

[perki]

Consent-page discrepancy explained (verified server-side): the auth flow skips the consent panel when the account already holds an app access matching the requestingAppId — our original run consumed the one-time consent for repro-issue-2199, so every later login auto-accepts (confirmed via the API's accesses/check-app, which returns a matchingAccess for that app id). To get the consent panel on every iteration, mint each authUrl with a unique requestingAppId (e.g. repro-issue-2199-$RANDOM). It doesn't invalidate your non-repro — but your 50 runs exercised login-only, no second same-page interaction.

Experiment status: the differential experiment is now live — credentials_enable_service: false set on all our dedicated MCP profiles (verified to persist across the MCP-launched Chrome restart), with the tripwire armed (capture-phase probe + OS-level screencapture on detection). Our usual long-lived agent sessions run daily on these profiles; we'll report either way within a few days.

[waltoss]

I had the same issue
I discovered that this is due to leak password modal that shows up when I use a breached password (in this case this is a testing app login is camille@patient.test / camille1234)

I hope it can help