Repository navigation
Local Cloak browser-run does not forward transient filechooser events #448
Description
Summary
webcmd browser run cannot receive a filechooser event from the local Cloak runtime, so an in-memory upload cannot be supplied to transient input[type=file] controls such as Flutter Web file_picker.
Reproduction
Environment:
- Webcmd 0.7.4
- Node 26.7.0
- Local Cloak runtime 0.4.5; reproduced again after testing 0.5.9
Create an isolated browser session and run this program:
await page.setContent(`
<button id="pick">Attach PDF</button><output id="result"></output>
<script>
document.querySelector('#pick').addEventListener('click', () => {
const input = document.createElement('input');
input.type = 'file';
input.accept = '.pdf';
input.style.display = 'none';
input.addEventListener('change', () => {
document.querySelector('#result').textContent = input.files[0]?.name ?? '';
});
document.body.appendChild(input);
input.click();
input.remove();
});
</script>
`);
const pending = page.waitForEvent('filechooser', { timeout: 5000 });
await page.getByRole('button', { name: 'Attach PDF' }).click();
const chooser = await pending;
await chooser.setFiles({
name: 'evidence.pdf',
mimeType: 'application/pdf',
buffer: new TextEncoder().encode('%PDF-1.4'),
});
return await page.locator('#result').textContent();Expected
The program receives the file chooser and reports evidence.pdf. File payloads remain in memory; host filesystem paths are not needed.
Actual
The program times out waiting for filechooser (the overall browser-run limit is reached when no shorter timeout is supplied).
Control
The equivalent regression runs successfully in Webcmd's runBrowserProgram test with playwright-core; the failure occurs only through the real local Cloak runtime bridge. Updating Cloak from 0.4.5 to 0.5.9 did not change the result.
Requested behavior
Forward Page.filechooser through the local Cloak browser-run bridge so callers can use the existing FileChooser.setFiles API with in-memory payloads, including inputs that are removed immediately after click().
Activity
Ayushraj06-bit commentedon Sep 13, 2026
I tried to reproduce this against the real local Cloak runtime (cloakbrowser 0.4.5, Chromium 146.0.7680.177.5, headed persistent context) and the file chooser turns out to be fine — it's the first line of the program that hangs.
Running your program unchanged reproduces the timeout. Changing only
page.setContent(...)topage.goto('data:text/html,' + encodeURIComponent(html))and leaving the rest identical:So
filechooseris forwarded through the bridge,FileChooser.setFilesworks with in-memory payloads, and the input being removed right afterclick()is not a problem.What fails is
page.setContent(), which on Cloak applies the markup and then never resolves:Cloak's Chromium accepts
Runtime.enablebut never emitsRuntime.consoleAPICalled. Playwright resolvesFrame.setContenton aconsole.debug(<tag>)sentinel it writes from the utility world next todocument.write, so the promise never settles. Your program spends its whole budget on statement one, which is why it looked like afilechoosertimeout — and why the control passed: withplaywright-coreand a stock Chromium,setContentresolves normally. That also explains why Cloak 0.5.9 made no difference; it is the browser binary, not the wrapper.Workaround today: navigate to the markup instead of setting it.
#528 makes browser run say this instead of
Split the task into a smaller run or increase --timeout, which is the part that currently sends you back around the same 30s wall. It does not makesetContentwork — that needs a fix in Cloak's Chromium.One side effect worth noting separately: because those console events never arrive,
page.on('console')also never fires on the default runtime, so page-sideconsole.logis silently dropped in browser run. Happy to open that as its own issue if useful.fix(browser): name the Cloak setContent hang instead of advising a lo…
Ayushraj06-bit commentedon Sep 13, 2026
Correction to the workaround I posted above, and an upstream link.
This is a known CloakBrowser bug — CloakHQ/cloakbrowser#360, opened 2026-06-07. Cloak-HQ confirmed and root-caused it to the browser binary's DevTools layer and said a fix was going into the next binary build. It is still open, and I've confirmed it still reproduces on the current binary (
146.0.7680.177.5, wrapper0.4.5).They publish a better workaround than the
data:URL I suggested — it keeps the page on its current origin instead of navigating away, which matters if you are mid-session on a real site:I verified this end to end through
browser runon real Cloak with your exact program: it completes in 21ms, leavespage.url()untouched, and the file chooser then resolves toevidence.pdf.#528 has been updated to point at this recovery rather than the
data:URL.fix(browser): name the Cloak setContent hang instead of advising a lo…