Don't delete an attachment dropped onto one that can't form a gallery - #1236
Open
lylo wants to merge 1 commit into
Open
Don't delete an attachment dropped onto one that can't form a gallery#1236lylo wants to merge 1 commit into
lylo wants to merge 1 commit into
Conversation
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.
Contributor
There was a problem hiding this comment.
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1235.
#dropOntoImageremoved the dragged node before working out whether a gallery could take it, and re-inserted it only when$findOrCreateGalleryForImagereturned one. Dropping a PDF or a video onto another attachment therefore deleted it: the drop target is resolved in the DOM againstfigure.attachment--preview, which matches any previewable attachment, whileImageGalleryNode.isValidChildgates onisPreviewableImageand 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
mainwithtoHaveCount(2)receiving1, and passes here.The rest of
attachment_drag_and_drop.test.js,drop_in_gallery.test.jsandgallery.test.jsstill pass, 40 tests in Chromium.Not addressed here
Two related things, deliberately left out to keep this to the data-loss fix:
attachment--previewcheck is broader thanisValidChild. The drop is now harmless, but the affordance is still misleading.