fix: preserve block content when appending text at cursor#446
Merged
fix: preserve block content when appending text at cursor#446
Conversation
Block attributes can be RichTextData objects (which have toString/valueOf
methods) rather than plain strings or {raw, rendered} objects.
normalizeAttribute incorrectly converts these to empty strings because
RichTextData lacks a .raw property, causing the existing block content
(e.g. a typed "@" trigger) to be lost when appendTextAtCursor rebuilds
the block.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
appendTextAtCursor passed block content through normalizeAttribute(),
which is designed for entity record attributes ({raw, rendered} objects).
Block attributes from getBlock() can be RichTextData objects, which lack
a .raw property. normalizeAttribute converted these to empty strings,
discarding the existing block content (e.g. "Hi, my block and @") before
inserting the appended text.
Revert to the original fallback (`|| ''`) which lets RichTextData pass
through to create(), where its toString() method correctly produces the
HTML string.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Present a simple picker with hardcoded suggestions when the @ or + autocompleter triggers in the iOS and Android demo apps. This enables manual testing of the appendTextAtCursor bridge method. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4 tasks
jkmassel
approved these changes
Apr 9, 2026
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.
What?
Revert the
normalizeAttribute()call on block content inappendTextAtCursor, which was incorrectly discarding existing block text.Why?
#429 introduced
normalizeAttribute()to handle{raw, rendered}objects from the WordPress data store. It was also applied toblock.attributes.contentinappendTextAtCursor, but block attributes fromgetBlock()areRichTextDatainstances — not{raw, rendered}objects. SinceRichTextDatalacks a.rawproperty,normalizeAttribute()returned an empty string, discarding all existing block content before the insertion.This caused @mentions (and any
appendTextAtCursorusage) to lose existing block content. For example, typing@in a paragraph and selecting a mention would replace the entire block content with just the username, dropping both the@trigger and any preceding text.Reported via WordPress-Android#22764.
How?
Reverted
block.attributes.contenthandling inappendTextAtCursorto the original|| ''fallback, which letsRichTextDataobjects pass through tocreate()where theirtoString()method correctly produces the HTML string.normalizeAttribute()remains in place for entity record attributes (getEditedPostAttribute,getEditedPostContent) where{raw, rendered}objects are expected.Testing Instructions
@@prefixgbk-auto-complete.mov