fix(iOS): caret renders inside inline images after attribute reapplication#517
fix(iOS): caret renders inside inline images after attribute reapplication#517fendent wants to merge 1 commit intosoftware-mansion:mainfrom
Conversation
The nuke-and-recreate cycle in handleDirtyRangesStyling removes all attributes (including NSAttachmentAttributeName) then re-adds them. Without batching, each mutation triggers a separate layout pass. Between the remove and re-add, TextKit sees the object replacement character with no attachment and calculates zero glyph width, causing the caret to render inside inline images. Wrapping in beginEditing/endEditing coalesces the changes into a single layout pass so the transient zero-width state is never visible.
|
Hi @fendent, |
There was a problem hiding this comment.
Pull request overview
This PR fixes a visual rendering issue on iOS where the text caret overlaps with inline images instead of appearing at the image's edge. The root cause is that handleDirtyRangesStyling in AttributesManager removes and re-applies attributes in separate operations, causing TextKit to perform intermediate layout passes where the \uFFFC placeholder character temporarily has zero glyph width. The fix wraps the attribute reset and re-application cycle in beginEditing/endEditing calls so TextKit processes all changes as a single atomic operation.
Changes:
- Wrapped attribute reset and re-application in
beginEditing/endEditingto ensure TextKit performs atomic layout passes - Added explanatory comment describing the caret rendering issue and its solution
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
Fixes an issue where the text caret visually overlaps with inline images (renders inside the image bounds rather than at its edge).
The root cause is in
handleDirtyRangesStylinginAttributesManager. The method removes all attributes from a dirty range (includingNSAttachmentAttributeName) then re-adds them. Each mutation triggers a separate TextKit layout pass. Between the remove and re-add, TextKit sees the\uFFFCcharacter with no attachment and calculates zero glyph width, causing the caret to be positioned inside the image.The fix wraps the reset+reapply cycle in
beginEditing/endEditingso TextKit processes all attribute changes as a single atomic layout pass.Test Plan
setImageCompatibility
Checklist