Repository navigation
id(web): multi-image paste/drop inserts images in upload-completion order, not clipboard order #1323
Description
Bug
Pasting or dropping multiple images at once into the id web editor inserts them in upload-completion order, not clipboard order. Uploads race: whichever /api/upload request finishes first does not determine position — in the verified probe below, the image whose upload finished first ended up second in the document. The resulting order is effectively nondeterministic and depends on file sizes and network timing.
Evidence
pkgs/id/web/src/image-upload.ts:
handlePaste(~L185-202) andhandleDrop(~L204-228) start every file's upload from the same insert position (view.state.selection.from/ oneposAtCoordsresult) via independenthandleImageUpload(view, file, insertPos)calls — no sequencing or ordering token.handleImageUpload(~L232-245) adds a placeholder widget at that shared position; on completion it inserts the image node at its placeholder's mapped position (found[0].from). All placeholders sit at the same document position, so completion order — not paste order — decides the final sequence.
Verified this run on main 1bf2afb2 with a targeted vitest probe (real EditorView + plugin, mocked fetch; probe since removed):
- Pasted
[first.png, second.png]; resolved second.png's upload first, then first.png's. - Resulting document image order:
[second.png, first.png]— reversed relative to the clipboard.
With equal timing the order varies run to run; larger files (slower uploads) systematically drift later/earlier than the user pasted them.
Why it matters
Multi-image paste is the normal way users add screenshots and photo sets to a document. Silently scrambling their order corrupts the document's meaning (before/after shots, step-by-step screenshots, comic/panel sequences) and the user may not notice until the document is shared — in a collaborative editor, possibly after collaborators have seen the scrambled version.
Acceptance criteria
- Images pasted or dropped together appear in the document in clipboard/file-list order, regardless of individual upload completion order (e.g. sequence the insertions, or give each placeholder a stable ordered slot that later completions insert after).
- A failed upload in the middle of a batch does not reorder or drop the remaining images; its placeholder is removed and the survivors keep their relative order.
- Regression test in
pkgs/id/web/src/image-upload.test.ts: real-view probe like the one above — paste two images, resolve the uploads out of order, assert document order matches paste order; same for the failure-in-the-middle case. - Single-image paste/drop behavior unchanged; existing web tests pass (
cd pkgs/id/web && bun run test/ vitest).
Related but distinct: #1321 (an all-oversized paste/drop is swallowed entirely) touches the same handlers.
Activity
developing-today commentedon Oct 27, 2026
CODE-432
dezren39 commentedon Oct 27, 2026
🤖 Agent note · state: filed
dezren39 commentedon Oct 27, 2026
Intake review
Fleet monitor intake pass (protocol §5), 2026-10-27. Verified still live: no merged PR implements or resolves this issue as of this run, and no duplicate open issue covers it.
Related: Related: sibling #1321 (all-oversized paste/drop swallowed) touches the same handlers and already has task 1311 queued; this issue's own triage task 1312 is queued. Acceptance criteria were already in the body under the heading; labels were already normalized by the filer — this pass only adds the intake review + meta/enriched.
Notes / risks / suggested approach: Risk: ordering fix must not break the single-image path or placeholder cleanup on failure. Suggested approach per the filer: sequenced insertion or stable ordered placeholder slots, with the out-of-order-completion regression test.
Labels normalized by this pass: meta/enriched.
dezren39 commentedon Oct 31, 2026
🤖 Agent note · picked up
5 remaining items
dezren39 commentedon Oct 31, 2026
🤖 Agent note · resumed, re-parked on CI
6699f099bOPEN/MERGEABLE; checks still pending (nix-ci, merge-queue-enqueue, treefmt-check) in the fleet runner backlog; no Codex review has landed yet.dezren39 commentedon Oct 31, 2026
agent-note:v1 — Agent: repo-worker-code (lane B); state: claimed. Task 1312 resumed for PR #3194 merge: Codex review on head 6699f09 completed with no findings; targeted suite verified on the laptop at the exact PR head (bunx vitest run src/image-upload.test.ts — 45/45 pass in a clean worktree). Note: .github/workflows/id-check.yml has no pull_request trigger (push-to-main + dispatch only), so no PR CI run exists for this head; the push-to-main run after merge is the CI gate. Merging under the standing directive.
Merge pull request #3194 from developing-today/queue/1312-1323-paste-…