[GH-ISSUE #161] bug: Terminal has no way to copy selected text (desktop web & mobile) #83

New issue

Open

opened 2026-10-18 14:02:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:02:45 +00:00

Owner

Originally created by @chitacdcolorrrr on GitHub (Jul 22, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/161

Bug

Text selected in the web terminal can never reach the clipboard. There is no working copy path on desktop browsers, and no copy affordance at all on touch devices. Paste works fine (via keyboard), so the terminal is effectively one-way.

Reproduction

Run cptr run --host 0.0.0.0, open the UI from another device (or any browser).
Open a terminal, run a command, drag-select some output text.
Try to copy it:
- Cmd+C / Ctrl+Shift+C → nothing lands on the clipboard
- Right-click → no context menu appears
- On touch devices → long-press selection doesn't work, and there is no copy button

Root cause (from the shipped frontend bundle, v0.9.12)

The terminal's custom input layer registers these handlers:

pointerdown/move/up  → forwarded over the WebSocket
keydown/keyup        → forwarded over the WebSocket
paste                → reads e.clipboardData and forwards the text   // paste works
contextmenu          → e.preventDefault()                            // native menu killed
copy                 → (no listener at all)

So:

No copy event handler exists. The selection highlight is purely visual (canvas-rendered, not a DOM selection), so the browser's built-in copy can't help, and nothing moves selectionText into the clipboard.
contextmenu is preventDefault'd, which also defeats xterm.js's built-in right-click fallback (focus hidden textarea + select text so the native menu's "Copy" works).
The only selection-driven path in the bundled xterm fork is onLinuxMouseSelection, which just populates the hidden textarea (X11 PRIMARY semantics) — no clipboard write, and Linux-only anyway.

Side note: all other copy buttons in the UI use navigator.clipboard.writeText() with no fallback. When the UI is served over plain HTTP on a LAN IP (http://192.168.x.x:8000), that's not a secure context, so navigator.clipboard is undefined and those buttons silently fail too. A warning toast would help discoverability.

Suggestions

Add a copy event listener on the terminal's input element: e.clipboardData.setData('text/plain', term.getSelection()) works even in insecure contexts, no permissions needed — this fixes keyboard copy on desktop for free.
Don't blanket-preventDefault contextmenu on desktop; or replace it with a small custom menu (Copy / Paste) like most web IDEs do.
On touch: show a floating "Copy" button when the selection is non-empty.
Add an execCommand('copy') fallback or a visible warning when navigator.clipboard is unavailable.

Environment

cptr 0.9.12 (installed via pipx), host: macOS (Apple Silicon)
Clients tested: desktop Chrome and mobile browser over LAN HTTP

Disclosure: this issue was investigated, root-caused, and drafted by Kimi K3 while helping me debug the terminal copy behavior in a chat session, and is submitted on my behalf at my request. The analysis above is based on reading the shipped v0.9.12 frontend bundle; I verified the described behavior reproduces on my setup.

Originally created by @chitacdcolorrrr on GitHub (Jul 22, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/161 ## Bug Text selected in the web terminal can never reach the clipboard. There is no working copy path on desktop browsers, and no copy affordance at all on touch devices. Paste works fine (via keyboard), so the terminal is effectively one-way. ## Reproduction 1. Run `cptr run --host 0.0.0.0`, open the UI from another device (or any browser). 2. Open a terminal, run a command, drag-select some output text. 3. Try to copy it: - `Cmd+C` / `Ctrl+Shift+C` → nothing lands on the clipboard - Right-click → no context menu appears - On touch devices → long-press selection doesn't work, and there is no copy button ## Root cause (from the shipped frontend bundle, v0.9.12) The terminal's custom input layer registers these handlers: ```js pointerdown/move/up → forwarded over the WebSocket keydown/keyup → forwarded over the WebSocket paste → reads e.clipboardData and forwards the text // paste works contextmenu → e.preventDefault() // native menu killed copy → (no listener at all) ``` So: 1. **No `copy` event handler exists.** The selection highlight is purely visual (canvas-rendered, not a DOM selection), so the browser's built-in copy can't help, and nothing moves `selectionText` into the clipboard. 2. **`contextmenu` is `preventDefault`'d**, which also defeats xterm.js's built-in right-click fallback (focus hidden textarea + select text so the native menu's "Copy" works). 3. The only selection-driven path in the bundled xterm fork is `onLinuxMouseSelection`, which just populates the hidden textarea (X11 PRIMARY semantics) — no clipboard write, and Linux-only anyway. Side note: all other copy buttons in the UI use `navigator.clipboard.writeText()` with no fallback. When the UI is served over plain HTTP on a LAN IP (`http://192.168.x.x:8000`), that's not a secure context, so `navigator.clipboard` is `undefined` and those buttons silently fail too. A warning toast would help discoverability. ## Suggestions - Add a `copy` event listener on the terminal's input element: `e.clipboardData.setData('text/plain', term.getSelection())` works even in insecure contexts, no permissions needed — this fixes keyboard copy on desktop for free. - Don't blanket-`preventDefault` `contextmenu` on desktop; or replace it with a small custom menu (Copy / Paste) like most web IDEs do. - On touch: show a floating "Copy" button when the selection is non-empty. - Add an `execCommand('copy')` fallback or a visible warning when `navigator.clipboard` is unavailable. ## Environment - cptr 0.9.12 (installed via pipx), host: macOS (Apple Silicon) - Clients tested: desktop Chrome and mobile browser over LAN HTTP --- _Disclosure: this issue was investigated, root-caused, and drafted by Kimi K3 while helping me debug the terminal copy behavior in a chat session, and is submitted on my behalf at my request. The analysis above is based on reading the shipped v0.9.12 frontend bundle; I verified the described behavior reproduces on my setup._

bsakaguchi referenced this issue

2026-10-18 14:04:21 +00:00

[PR #83] [MERGED] 0.7.1 #278