Skip to content

[lexical-clipboard][lexical] Bug Fix: Preserve source semantics and boundaries in text drops - #9180

Closed
kazemek21 wants to merge 1 commit into
facebook:mainfrom
kazemek21:kylez_NEXUS-2154_lexical-drop-target
Closed

kazemek21 wants to merge 1 commit into
facebook:mainfrom
kazemek21:kylez_NEXUS-2154_lexical-drop-target

Conversation

@kazemek21

Copy link
Copy Markdown

Description

Marked text drops can remove the selected text at a source-range endpoint, and splitting an element caret can move an insertion outside an empty custom block. This recognizes equivalent text-edge and adjacent element-boundary endpoints without collapsing distinct block boundaries, preserves stable element carets, and keeps the active source selection mapped when rich-text targets require a text split. For drop no-op checks, both immediately adjacent sides of an empty text source endpoint are inclusive; this does not change structural caret identity or extend across an unselected neighbor or block.

$handlePlainTextDrop gains an optional synchronous, read-only target resolver with a small destination preparation callback. Plain-text insertion finishes before source removal, so a preparation or insertion error preserves the dragged source even when onError rethrows. Preparation may establish a new collapsed destination selection. Target splits remap the active source selection; source-facing carets track it through preparation without extracting source text, preserving token deletion, custom text-node types, and removal of empty unmergeable source endpoints. Rejected targets and unsupported plain-text payloads consume the marked drop without deleting its source. Unmarked native drops retain their existing handling.

The optional API is limited to plain text. Rich-text importers keep their existing contract; the change does not infer payload insertion from formatting or selection changes. If rich source removal detaches the destination, the handler now reports an error instead of silently completing after deletion; recovery still depends on the editor’s normal error cleanup. Documentation specifies callback constraints, native cancellation, independent cross-editor undo and the limits of rollback: later transforms and separate editor updates are not atomic, and a rethrowing onError may retain partial destination edits.

Verification

Verification on this commit:

  • 126 focused clipboard/drop unit tests and 42 browser cases across Chromium and WebKit passed.
  • Existing TextDragDrop E2E in rich mode: Chromium 4 passed/1 mode skip; WebKit 3 passed/2 mode or engine skips. In plain mode: Chromium 2 passed/3 rich-mode skips; WebKit 1 passed/4 rich-mode or engine skips. The plain mode exercises the registered two-argument handler without a resolver.
  • Source and changed-test TypeScript, declaration build, Flow (including public consumer negative cases), package build, ESLint, formatting and normal commit hooks passed.
  • The preserved lint-flow comparison on the unchanged public declarations fails with 328 diagnostics on both base and candidate, with no additions or removals; it is not claimed as a passing final-head check.

The browser fixture uses real layout/hit-testing and synthetic drop events. The existing Chromium E2E additionally exercises native external dragging. Regression coverage includes same/cross-editor moves, source preservation on synchronous failures, caret placement, structural preparation, exact endpoints and undo.

Posted by Codex (gpt-6-astra) on behalf of kylez.

…oundaries in text drops

## Description

Treat inclusive source endpoints as drop no-ops before preparation or import. Compare adjacent text edges within one parent, including both sides of an empty text source endpoint, without changing insertion carets or crossing block boundaries.

Add an optional synchronous resolver and destination preparation callback to plain-text drops. Stabilize targets with the source active, retain source text modes and empty deletion slices, and remove the source once after insertion returns. Preserve the source on synchronous preparation/insertion failures. Reject parentless sibling targets before preparation while allowing root child carets and valid element offsets.

Keep rich importer behavior and its existing rollback dependence without an insertion-success heuristic.

## Verification

Same-editor and cross-editor root-sibling targets previously reported "Expected node root to have a parent" instead of a graceful veto:

```text
Tests  2 failed | 113 skipped (115)
```

After correction:

```text
Tests  126 passed (126)
Tests  42 passed (42)
Found 0 errors
```

The new cases verify cancellation once, no error/preparation/source deletion, no cross-editor deleteByDrag, and unchanged keys, structure, selection and history. Existing root-child, endpoint, source-mode, preparation, multiline caret and undo controls pass.

Upstream TextDragDrop E2E passed/skipped: rich Chromium 4/1, rich WebKit 3/2; plain Chromium 2/3, plain WebKit 1/4. Skips are existing mode gates and WebKit's native external-drag exclusion. Marked browser cases use real hit testing with synthetic events; native external dragging passes separately in Chromium.

Source/test TypeScript with negative callback controls, Flow full-check with two workers, declaration/development builds, full ESLint and Prettier pass. Historical Flow export parity retains 328 baseline/candidate diagnostics and is not claimed green. No full unit suite rerun.

Posted by Codex (gpt-6-astra) on behalf of kylez.
@meta-cla

meta-cla Bot commented Sep 18, 2026

Copy link
Copy Markdown

Hi @kazemek21!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

@vercel

vercel Bot commented Sep 18, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
lexical Ready Ready Preview Sep 18, 2026 12:28pm UTC
lexical-playground Ready Ready Preview Sep 18, 2026 12:28pm UTC

Request Review

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.

1 participant