Repository navigation
Move whole lines as blocks when dragging or cutting - #6171
Conversation
The drag copies the selection as-is, so a selection running from the start of one line to the start of the next carries the line break. On drop, Transforms.delete unhung that range first, deleting only the text and leaving the now-empty block behind, while the dropped fragment re-added the break, so every such drag grew the document by an empty line. Delete with hanging: true so the removed range matches the dragged fragment. The Playwright test runs in Firefox only, the one engine that performs a native drag of a text selection under Playwright. Fixes #5376
🦋 Changeset detectedLatest commit: f141316 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
Moving this back to draft. |
Deleting the dragged range with hanging: true fixed plain lines but merged containers elsewhere: a drag from the start of one table cell to the start of the next removed a cell, the paragraph after a list was pulled into the list, and the block after a dragged heading became a heading. Decide per range instead. When a range runs from the start of one top-level block to the start of a later one, keep the hanging fragment and remove those blocks outright, without merging anything. Otherwise, unhang the range before copying it, so the fragment matches what the unhung delete removes. Cut gets the same rule, since it had the same extra-line bug. The drop now deletes through editor.deleteFragment, as cut does, so plugins that guard deletion cover both. The tables example uses that hook to clear a cross-cell selection cell by cell instead of merging cells. Dropping onto the dragged selection itself now does nothing. Tests: unit tests for the range helper (plain lines, headings, quotes, lists, tables, empty lines, inline starts), plus Playwright drag tests (Firefox only) and cut tests (all browsers) in the plaintext, richtext and tables examples. All but the drop-onto-itself test fail on main.
Resolves the conflict with ianstormtaylor#6171 in `<Editable>`'s `onDrop`: its handling of internal drags (skip drops onto the dragged range, move via `deleteMovedRange`) now runs inside the branch that has a drop range, while a drop without one keeps falling back to the selection or leaving internal drags in place.
Fixes #5376
Dragging or cutting a selection that runs from the start of one line to the start of the next copies the line break, but the delete unhung the range and left the emptied block behind. Each move grew the document by one empty line.
The first version of this PR deleted with
hanging: true. That merged containers: a cell drag removed a table cell, the paragraph after a list was pulled into the list, and the block after a dragged heading became a heading. This version decides per range:editor.deleteFragment, as main does for cutAlso:
editor.deleteFragment(as cut already did), so plugins that guard deletion cover both.Tests:
packages/slate-react/test/move-range.spec.ts(13 cases): plain lines, backward selections, headings, quotes, several lines at once, empty lines, a non-hanging range, an inline start, list items, a list followed by a paragraph, table cells, table rows, and thedeleteFragmenthook.Known limit: nested moves leave the emptied list item or cell in place (main does the same), because removing it can't be done generically without breaking tables.