Skip to content

Fix/desktop image paste - #511

Closed
mrsharpoblunto wants to merge 4 commits into
Ark0N:masterfrom
mrsharpoblunto:fix/desktop-image-paste
Closed

mrsharpoblunto wants to merge 4 commits into
Ark0N:masterfrom
mrsharpoblunto:fix/desktop-image-paste

Conversation

@mrsharpoblunto

Copy link
Copy Markdown

No description provided.

mrsharpoblunto and others added 4 commits September 30, 2026 00:44
Desktop Ctrl+V image paste was silently dropped whenever
DataTransferItem.getAsFile() returned null or the image item arrived
with an empty MIME type (seen in Chrome and Firefox, Codex and Claude
sessions).

- image-input.js: _collectPastedImages() now probes empty-MIME file
  items, reads clipboardData.files, guards getAsFile() nulls/throws,
  dedups blobs seen via both items and files, and reports sawImageData
  so the trap can try the async navigator.clipboard.read() fallback
  instead of dying silently (with a toast when recovery fails).
- keyboard-accessory.js: composer/textarea paste handlers share the
  same file-local collection rules.
- Duplicate-paste invariant preserved: one Ctrl+V may emit two paste
  events; the trap still consumes only the first.
Some engines leave navigator.clipboard.read() pending forever when
the permission prompt can never be answered (observed in headless
Firefox, which does expose the API). Race the read against a 10s
timeout so the paste trap always reaches the failure toast instead
of silently doing nothing.
Local-fs save died as 500 ENOENT for remote-SSH cases, whose workingDir
lives on another host. Pipe validated bytes over ssh (mkdir, probe-verify
dir containment, stream via stdin); unreachable hosts map to 502.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant