Repository navigation
fix(tui): read clipboard images through Windows interop on WSL - #57470
AlexeyShirshov wants to merge 1 commit into
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
3b09507 to
285b8a9
Compare
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The fallback looks correct, but I couldn't check it on real WSL: this sandbox has no Windows interop or Windows clipboard. Instead I put a fake powershell.exe on PATH and called createClipboardAdapter with a stubbed native read. An image comes back as image/png base64 and an empty Windows clipboard returns nothing. A failing or missing powershell.exe now throws, and the prompt's paste queue catches that and shows it, instead of the paste silently doing nothing. Cancelled reads and non-WSL systems are unchanged. bun test test/clipboard.test.ts and the packages/tui typecheck pass.
Public API: unchanged.
One thing worth fixing: WSL detection also matches Docker Desktop containers and devcontainers on Windows, where the error message would be misleading (see the inline comment).
Related: #55639
| ].join("; ") | ||
|
|
||
| function isWSL() { | ||
| return process.platform === "linux" && (Boolean(process.env.WSL_DISTRO_NAME) || release().includes("WSL")) |
There was a problem hiding this comment.
release().includes("WSL") also matches containers on Docker Desktop and devcontainers on Windows: they run the microsoft-standard-WSL2 kernel but have no Windows interop. There, pressing Ctrl+V with nothing readable on the clipboard now throws "needs powershell.exe interop" where it used to be a silent no-op, and the message is misleading. Checking only what WSL itself sets (WSL_DISTRO_NAME / WSL_INTEROP) covers WSL1 and WSL2 and avoids this, since those variables don't reach containers.
There was a problem hiding this comment.
Fixed in 1052174: detection now only checks the variables WSL sets (WSL_DISTRO_NAME / WSL_INTEROP), so containers on the WSL kernel keep the previous silent no-op instead of throwing a misleading interop error. Verified both paths here: with the variables set the Windows clipboard image comes back as image/png; with them unset the read returns undefined.
285b8a9 to
05a47ef
Compare
The native host clipboard cannot read the Windows selection from WSL, so pasting a screenshot did nothing. Fall back to powershell.exe and report interop failures instead of returning undefined.
05a47ef to
1052174
Compare
This branch has not been deployed
1 participant
Issue for this PR
Fixes #49895
Type of change
What does this PR do?
On WSL the native host clipboard has nothing to read: Windows Terminal owns the selection and OpenTUI's Linux backend has no bridge to it, so
read()returnedunsupportedand Ctrl+V on an image did nothing. When the native read fails and the platform is WSL,createClipboardAdapternow falls back to the Windows clipboard throughpowershell.exeand returns the image asimage/pngbase64 - the same interop path V1 used.If the interop is missing or powershell fails,
read()throws instead of returningundefined, so the TUI shows an error instead of failing silently. Non-WSL reads and cancelled reads are unchanged, and a working WSLg still answers first, so the fallback only runs when the native read has nothing.How did you verify your code works?
On WSL2 (kernel
6.18.33.2-microsoft-standard-WSL2, no WSLg runtime dir, so no Wayland/X11 clipboard):unsupportedin ~2 ms, hence the silent no-op.image/pngbase64 and the TUI attaches it.undefined; text paste still goes through the terminal as before.bun test test/clipboard.test.tsandoxlintpass.There is no automated test for the powershell path: it depends on Windows interop being present. The change was exercised through the clipboard adapter against the real Windows clipboard; I did not drive the whole TUI by hand. The native adapter tests in
packages/tui/test/clipboard.test.tsstill cover the unchanged read/write behaviour.Checklist
Added by the opencode bot (AI-generated).
Related: #55639