upload_file on a chooser-opening element crashes the tab with RESULT_CODE_KILLED_BAD_MESSAGE

[peepers-rick]

Description of the bug

Calling upload_file with the uid of an element that opens the file chooser (e.g. a button that calls input.click(), which is how most real-world upload UIs work — the actual <input type="file"> is hidden) crashes the Chrome tab with RESULT_CODE_KILLED_BAD_MESSAGE ("Aw, Snap!"). The browser process kills the renderer, presumably over the file-chooser interception IPC.

Calling upload_file with the uid of the <input type="file"> element itself works correctly (file is set, change event fires).

The tool description explicitly documents the chooser-opening-element case as supported:

The uid of the file input element or an element that will open file chooser on the page from the page content snapshot

The tool response after the crash is misleading — it reports Error: Element with uid X no longer exists on the page. because the whole tab has crashed, so an agent has no way to tell the page died and typically keeps flailing. This has been reproducible for months across projects.

Reproduction

Self-contained repro (no external site needed):

1. new_page with this URL:

   data:text/html,<h1>upload test</h1><input type="file" id="f"><button onclick="document.getElementById('f').click()">Choose via chooser</button><div id="out"></div><script>document.getElementById('f').addEventListener('change',e=>{document.getElementById('out').textContent='GOT: '+e.target.files[0].name})</script>
   

2. take_snapshot → note the uid of the button ("Choose via chooser")
3. upload_file with that button's uid and any local file path
4. Tab crashes: "Aw, Snap! RESULT_CODE_KILLED_BAD_MESSAGE". Tool returns Error: Element with uid <uid> no longer exists on the page.

Control: step 3 with the uid of the <input type="file"> element instead succeeds — snapshot afterwards shows value="upload-test.txt" and StaticText "GOT: upload-test.txt".

Expectation

upload_file on a chooser-opening element intercepts the chooser and sets the file, as documented — or at minimum fails gracefully without killing the renderer, and reports the tab crash rather than "element no longer exists".

MCP configuration

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest --browserUrl http://172.19.96.1:9222

Connecting from WSL2 to a user-launched Chrome on the Windows host started with --remote-debugging-port=9222 (headful, real profile).

Chrome DevTools MCP version

1.5.0

Chrome version

Chrome/150.0.7871.47 (Windows x64, headful)

Coding agent version

Claude Code 2.1.201

Model version

claude-fable-5

Node version

v22.22.0

Operating system

Windows Subsystem for Linux (WSL)

[OrKoN]

I am not able to reproduce 150.0.7871.47 (Official Build) (arm64) on a Mac. Upload works with both uids for me.

[OrKoN]

Do you have the crash ID from chrome://crashes from Chrome?

[peepers-rick]

Thanks for looking @OrKoN. Two things explain the non-repro:

1. It's nondeterministic. On my machine upload_file against a chooser-opening element crashes the renderer intermittently, not every time — this session it fired on 2 of ~4 identical calls (same page, same element, same file). Looks like a race in the file-chooser interception path rather than a deterministic bad call, so a single attempt can easily come up clean.

2. Platform. I'm on Windows Chrome 150.0.7871.47 (x64), driven from WSL2 over --browserUrl; you tested macOS arm64. Renderer-kill races like this are often OS-specific. Minimal repro (crashes intermittently — retry a few times):

data:text/html,<input type="file" id="f" style="display:none"><button onclick="document.getElementById('f').click()">upload</button>

take_snapshot → upload_file with the button's uid.

Crash ID: uploaded from chrome://crashes —

Uploaded Crash Report ID: 474924bd77224014
Upload Time: 2026-07-07 08:27:27

(local Crashpad dump was 3cf9331f-2664-45b6-888b-1d6fc8939c4e, crash at 2026-07-06 14:12:26.)

Re #2311/#2313: agreed the added test passes without the fix — the crash doesn't reproduce deterministically in a headless test the way the PR assumes. The real signal is the intermittent Windows renderer-kill, which the uploaded dump should pin down.

[OrKoN]

@peepers-rick thanks for the crash ID, this leads to https://g-issues.chromium.org/issues/488313885 that was expected to be fixed. Does anything change for you if you launch Chrome with --disable-blink-features=WebMCPDeclarativeFileInput --disable-features=WebMCPDeclarativeFileInput?

[OrKoN]

Unfortunately, I was not able to reproduce on my Windows installation as well.