Closed
Conversation
On Android, intercept paste actions before BasicTextField's plain-text
handler and route clipboard content through the existing HTML pipeline:
• ClipData.Item.htmlText → used directly (Chrome, Docs, Gmail, …)
• ClipData.Item.text is Spanned → converted via android.text.Html.toHtml()
(covers AppCompatEditText copies carrying StyleSpan, UnderlineSpan,
URLSpan, ForegroundColorSpan, StrikethroughSpan, etc.)
• Plain text (no spans) → returns false, default paste flow unchanged
Two intercept points are wired up:
- SpannedPasteTextToolbar wraps LocalTextToolbar to catch the
context-menu "Paste" action.
- onPreviewKeyEvent intercepts Ctrl+V / Cmd+V on hardware keyboards.
All non-Android targets receive a no-op actual that returns false.
The skipSigning Gradle property is added to module.publication.gradle.kts
to allow unsigned publishToMavenLocal builds during local development.
Also merges upstream PR MohamedRejeb#638 (fix StringIndexOutOfBoundsException in
MarkdownUtils for nested indented lists).
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
The previous implementation only covered two paste paths: • Long-press → context menu "Paste" (TextToolbar wrapper) • Hardware keyboard Ctrl/Cmd+V (onPreviewKeyEvent) Soft-keyboard IME paste (the "Paste" button in the IME toolbar or suggestion strip) goes through InputConnection.performContextMenuAction, which calls ClipboardManager.getText() directly — bypassing both of the above intercept points, causing plain-text to be inserted. Fix: RichTextClipboardManager.getText() now calls SpannedPasteHandler.readHtml() (new method). When HTML or Spanned content is found in the platform ClipData, it stores the HTML in RichTextState.pendingHtmlPaste and returns the plain-text fallback so the IME gets a valid cursor position. RichTextState.onTextFieldValueChange() consumes pendingHtmlPaste at its very top — before handleAddingCharacters runs — and replaces the would-be plain-text insertion with a proper insertHtmlAfterSelection() call. This path is also taken for TextToolbar / Ctrl+V pastes, but those are intercepted earlier (tryPasteSpanned) and never reach onTextFieldValueChange with pendingHtmlPaste set. All paste paths now preserve formatting: • Soft keyboard IME paste ← new • Context menu paste ← existing, still works • Hardware Ctrl/Cmd+V ← existing, still works • Plain text (no spans) ← falls through unchanged Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…Pasteboard - Add getHtmlIfMatch(addedText) to SpannedPasteHandler interface so onTextFieldValueChange can probe the clipboard when the IME paste button bypasses RichTextClipboardManager.getText() entirely - Implement getHtmlIfMatch in AndroidSpannedPasteHandler: compares the added text against clipboard plain text; returns HTML if they match - Replace iOS no-op with IosSpannedPasteHandler backed by UIPasteboard.generalPasteboard, covering all three paste paths: context menu (tryPasteSpanned), hardware keyboard (tryPasteSpanned), and soft keyboard / IME (getHtmlIfMatch) - Wire spannedPasteHandler into RichTextState via SideEffect so onTextFieldValueChange has access to the platform handler - Add PasteDebugLog expect/actual for all platforms (RichPaste tag) Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
iOS clipboard HTML carries the source page's background-color (usually white or transparent) on every span. Strip white/#fff/rgb(255,255,255)/ rgba(255,255,255,*) and transparent values so they don't render as white boxes behind text in the editor. Intentional highlight colors are left intact. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
MohamedRejeb
added a commit
that referenced
this pull request
Apr 17, 2026
Issue #626 reported that copying styled text from the editor and pasting into a plain-text target (e.g. the Android notes app) collapsed everything onto a single line. The issue was filed on 2025-10-21, before rich clipboard support landed in 3770676 (2026-04-11, PR #642). Before #642, the library relied on Compose's default copy, which reads from the transformed annotated string — and since the annotated string replaces '\n' with ' ' for rendering, the plain text payload lost paragraph breaks. #642 overrode setClipEntry on all platforms to build the payload from toText(copySelection) and toHtml(copySelection), both of which preserve '\n' and block tags. These tests lock in that behavior across seven scenarios: - copy across <p> paragraphs (plain and styled) - copy across <br> paragraphs (isFromLineBreak = true) - copy with mixed inline styles across <br> boundaries - mid-range copy that crosses a paragraph boundary - copy across an ordered list - toHtml(copySelection) preserves block-level tags Marking #626 as already fixed by #642.
Owner
|
Hello |
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
2 participants
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.
Preserve spans when user externally copy text and paste to editor