Skip to content

Don't delete an attachment dropped onto one that can't form a gallery - #1236

Open
lylo wants to merge 1 commit into
basecamp:mainfrom
lylo:fix-drop-onto-non-gallery-attachment
Open

Don't delete an attachment dropped onto one that can't form a gallery#1236
lylo wants to merge 1 commit into
basecamp:mainfrom
lylo:fix-drop-onto-non-gallery-attachment

Conversation

@lylo

@lylo lylo commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Fixes #1235.

#dropOntoImage removed the dragged node before working out whether a gallery could take it, and re-inserted it only when $findOrCreateGalleryForImage returned one. Dropping a PDF or a video onto another attachment therefore deleted it: the drop target is resolved in the DOM against figure.attachment--preview, which matches any previewable attachment, while ImageGalleryNode.isValidChild gates on isPreviewableImage and admits only raster images. When the two disagreed, the node was removed and never put back.

Resolving the gallery before mutating anything makes an unsupported drop a no-op.

Test

Adds a regression test under "Gallery creation": two PDFs, drag one onto the other, assert both survive and no gallery is created. It fails on main with toHaveCount(2) receiving 1, and passes here.

The rest of attachment_drag_and_drop.test.js, drop_in_gallery.test.js and gallery.test.js still pass, 40 tests in Chromium.

Not addressed here

Two related things, deliberately left out to keep this to the data-loss fix:

  • The gallery drop markers still appear over a target that cannot accept the drop, because the DOM-level attachment--preview check is broader than isValidChild. The drop is now harmless, but the affordance is still misleading.
  • Whether galleries should accept previewable PDFs at all is a separate question, which I'll raise on its own.

The drop target is resolved in the DOM against figure.attachment--preview,
which matches any previewable attachment, while gallery membership is decided
on content type and admits only images. #dropOntoImage removed the dragged
node before consulting the gallery and re-inserted it only when one came back,
so dropping a PDF or video onto another attachment deleted it outright.

Resolve the gallery first and bail out before mutating, making an unsupported
drop a no-op.
Copilot AI balanced review requested due to automatic review settings August 11, 2026 08:25

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Prevents data loss when dropping an attachment onto a previewable non-image that cannot form a gallery.

Changes:

  • Resolves gallery eligibility before removing the dragged node.
  • Adds PDF drag-and-drop regression coverage.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
src/editor/attachments/drag_and_drop.js Makes unsupported gallery drops no-ops.
test/browser/tests/attachments/attachment_drag_and_drop.test.js Verifies both PDFs survive an unsupported drop.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

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.

Dragging a PDF onto another PDF deletes it

2 participants