fix(bindx-editor): trim block-edge whitespace when deserializing pasted HTML#61
Merged
Merged
Conversation
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 #60.
Problem
Pasting HTML into a
BlockEditorprepends (and appends) a stray space whenever the source markup is indented / pretty-printed.HtmlDeserializer.deserializeTextNodecollapses a leading newline + indentation into a single space (text.replace(/[ \t]*(?:\r?\n[ \t]*)+/g, ' ')) but nothing trims that space at the block boundary, so<p>\n\t\tSome text\n</p>deserializes to" Some text "instead of"Some text". Users pasting from rendered pages get a leading space on essentially every paste.Fix
deserializeBlocksis the block-content boundary — it is called both at the top level (fromwithPaste) and for each block's children (from every block plugin'snext, e.g. paragraph / heading / list-item). After assembling a block's inlinetextsrun there, trim leading whitespace from the first text leaf and trailing whitespace from the last, descending through inline wrappers (anchors, etc.) to reach the edge leaf. This matches how a browser renders the same markup underwhite-space: normal. Interior whitespace between words is untouched.Tests
Added
tests/unit/editor/repro-paste-leading-space.test.ts:<p>\n\t\tSome text\n</p>yieldsSome text(no leading/trailing space)<p>\n\tfoo\n\t\tbar\n</p>→foo barThe first commit adds the test (red against
main); the second adds the fix (green). Fulltests/unit/editor/suite passes andbun run buildis clean.Notes / scope
Trimming is applied to the inline-
textsresult ofdeserializeBlocks. Loose text nodes that sit as siblings of block elements and get wrapped into a default element (thecontainsBlockbranch ofprocessNodeListPaste) are out of scope here — happy to extend if maintainers prefer a single normalization pass covering that case too.Reported downstream by a real end user pasting into a rich-text field; a temporary workaround (wrapping
editor.insertFragmentto trim the pasted fragment's edges) is shipped in the reporting project and will be removed once this lands.