fix: move.block guards against moving a block onto its own path#2688
Open
christianhg wants to merge 1 commit into
Open
fix: move.block guards against moving a block onto its own path#2688christianhg wants to merge 1 commit into
move.block guards against moving a block onto its own path#2688christianhg wants to merge 1 commit into
Conversation
The `move.block` operation handler unsets the source block, then inserts the same node before or after the destination path. When the destination resolves to the same block as the source, the `unset` shifts the surrounding indices and the follow-up `insert` lands at a path that no longer points at the intended slot. The block is eaten and the surrounding value silently loses an entry. The high-level `move.block up` / `move.block down` events do not hit this shape because they guard via `getSibling`, which returns `undefined` at the boundary and bails. Consumers reaching for the raw `move.block` event with caller-supplied origin and destination keys (custom drag-and-drop plugins, behaviors that compose the event from arbitrary path inputs) have no such guard - a drop on the same block was data loss. Adds an early return when origin and destination resolve to the same block. A single failing scenario in `tests/event.move.block.test.tsx` covers the case: sending `move.block` with `at` and `to` pointing at the same block leaves the value unchanged. Reverting the guard drops it back to red across all three browsers.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: d537930 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
📦 Bundle Stats —
|
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 765.1 KB | +72 B, +0.0% |
| Internal (gzip) | 147.1 KB | +14 B, +0.0% |
| Bundled (raw) | 1.37 MB | +72 B, +0.0% |
| Bundled (gzip) | 307.9 KB | +13 B, +0.0% |
| Import time | 93ms | -1ms, -1.2% |
@portabletext/editor/behaviors
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 467 B | - |
| Internal (gzip) | 207 B | - |
| Bundled (raw) | 424 B | - |
| Bundled (gzip) | 171 B | - |
| Import time | 2ms | -0ms, -1.9% |
@portabletext/editor/plugins
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 2.7 KB | - |
| Internal (gzip) | 894 B | - |
| Bundled (raw) | 2.5 KB | - |
| Bundled (gzip) | 827 B | - |
| Import time | 7ms | -0ms, -0.7% |
@portabletext/editor/selectors
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 79.9 KB | - |
| Internal (gzip) | 14.6 KB | - |
| Bundled (raw) | 75.9 KB | - |
| Bundled (gzip) | 13.6 KB | - |
| Import time | 8ms | -0ms, -1.3% |
@portabletext/editor/traversal
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 20.0 KB | - |
| Internal (gzip) | 4.0 KB | - |
| Bundled (raw) | 20.4 KB | - |
| Bundled (gzip) | 4.0 KB | - |
| Import time | 6ms | -0ms, -0.7% |
@portabletext/editor/utils
| Metric | Value | vs main (bf17021) |
|---|---|---|
| Internal (raw) | 30.0 KB | - |
| Internal (gzip) | 6.1 KB | - |
| Bundled (raw) | 27.9 KB | - |
| Bundled (gzip) | 5.7 KB | - |
| Import time | 6ms | -0ms, -0.1% |
🗺️ . · ./behaviors · ./plugins · ./selectors · ./traversal · ./utils · Artifacts
Details
- Import time regressions over 10% are flagged with
⚠️ - Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.
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
1 participant
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.
The
move.blockoperation handler unsets the source block, then inserts the same node before or after the destination path. When the destination resolves to the same block as the source, theunsetshifts the surrounding indices and the follow-upinsertlands at a path that no longer points at the intended slot. The block is eaten and the surrounding value silently loses an entry.The high-level
move.block up/move.block downevents do not hit this shape because they guard viagetSibling, which returnsundefinedat the boundary and bails. Consumers reaching for the rawmove.blockevent with caller-supplied origin and destination keys (custom drag-and-drop plugins, behaviors that compose the event from arbitrary path inputs) have no such guard - a drop on the same block was data loss.Reproduction
Fix
Early return from
moveBlockOperationImplementationwhen origin and destination resolve to the same block.A single failing scenario in
tests/event.move.block.test.tsxcovers the case. Reverting the guard drops it back to red across all three browsers (chromium / firefox / webkit).