Summary
Copying text inside a remote browser session never lands on the viewer's local clipboard, even when the live view is embedded with allow="clipboard-read; clipboard-write" per the docs.
Root cause
The neko server only delivers remote-clipboard updates to the session registered as host (sessions.GetHost() — the update is silently dropped when there is no host). The chromium-headful client runs with implicit hosting, and its remote.ts request() action bails when getters.hosting is true — which it always is under implicitHosting — so no session ever sends control/request, no host is ever registered, and clipboard updates are dropped for everyone.
This is the same bug upstream neko fixed in m1k1o/neko#540 (see also m1k1o/neko#499); the client vendored here predates that fix.
Verification (live against a production Kernel browser session)
From inside the live-view iframe of a live session:
- Baseline: select text remotely, send a real Ctrl+C keysym chord (
keydown 65507, keydown 99, …) over the data channel → no control/clipboard message ever arrives, navigator.clipboard.writeText never fires.
- Send
$client.sendMessage('control/request') once → server replies control/locked (session becomes host).
- Repeat the same Ctrl+C chord →
control/clipboard arrives with the selected text, writeText succeeds, and the local clipboard contains the remote selection. Copy works end-to-end.
So the server side already behaves correctly once a host exists; only the client-side request is missing.
Fix
Port m1k1o/neko#540 to the vendored client: request control on first interaction with the screen and gate request() on an explicit-host controlling getter instead of hosting. PR incoming.
Related (separate issue, mentioning for context)
macOS users pressing Cmd+C forward Meta+C to the remote Linux Chromium, which doesn't copy. The client special-cases paste (Cmd/Ctrl+V) but has no equivalent remap for copy — worth a follow-up.
Summary
Copying text inside a remote browser session never lands on the viewer's local clipboard, even when the live view is embedded with
allow="clipboard-read; clipboard-write"per the docs.Root cause
The neko server only delivers remote-clipboard updates to the session registered as host (
sessions.GetHost()— the update is silently dropped when there is no host). The chromium-headful client runs with implicit hosting, and itsremote.tsrequest()action bails whengetters.hostingis true — which it always is underimplicitHosting— so no session ever sendscontrol/request, no host is ever registered, and clipboard updates are dropped for everyone.This is the same bug upstream neko fixed in m1k1o/neko#540 (see also m1k1o/neko#499); the client vendored here predates that fix.
Verification (live against a production Kernel browser session)
From inside the live-view iframe of a live session:
keydown 65507,keydown 99, …) over the data channel → nocontrol/clipboardmessage ever arrives,navigator.clipboard.writeTextnever fires.$client.sendMessage('control/request')once → server repliescontrol/locked(session becomes host).control/clipboardarrives with the selected text,writeTextsucceeds, and the local clipboard contains the remote selection. Copy works end-to-end.So the server side already behaves correctly once a host exists; only the client-side request is missing.
Fix
Port m1k1o/neko#540 to the vendored client: request control on first interaction with the screen and gate
request()on an explicit-hostcontrollinggetter instead ofhosting. PR incoming.Related (separate issue, mentioning for context)
macOS users pressing Cmd+C forward Meta+C to the remote Linux Chromium, which doesn't copy. The client special-cases paste (Cmd/Ctrl+V) but has no equivalent remap for copy — worth a follow-up.