SD-2570 - fix: document API tracked changes not fully rendered on document#2825
SD-2570 - fix: document API tracked changes not fully rendered on document#2825chittolinag wants to merge 3 commits intomainfrom
Conversation
superdoc-bot
bot
added
review: thorough
review: careful
and removed
review: thorough
labels
This reverts commit 363336c.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9781989a3e
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if ((run as TextRun).text && typeof (run as TextRun).text === 'string' && (run as TextRun).text.includes('\n')) { | ||
| const textRun = run as TextRun; | ||
| const segments = textRun.text.split('\n'); | ||
| let cursor = textRun.pmStart ?? 0; |
There was a problem hiding this comment.
The newline expansion path seeds cursor with textRun.pmStart ?? 0, which means runs that originally had no PM mapping are rewritten with synthetic pmStart/pmEnd values. Those fabricated offsets are later emitted as data-pm-* attributes during rendering, so in documents rendered without real PM coordinates the caret/click mapping can resolve to incorrect positions (often near the document start) instead of using the no-position fallback path. Preserve pmStart/pmEnd as undefined when the source run has no PM metadata.
Useful? React with 👍 / 👎.
| }; | ||
|
|
||
| export const sliceRunsForLine = (block: ParagraphBlock, line: Line): Run[] => { | ||
| const runs = expandRunsForInlineNewlines(block.runs as Run[]); |
There was a problem hiding this comment.
This call now recomputes newline expansion for the full paragraph run list every time a single line is rendered. Since renderLine invokes sliceRunsForLine per measured line, long paragraphs incur repeated full-array scans and allocations, turning rendering into avoidable O(lines × runs) work and causing noticeable paint slowdowns on large documents with tracked changes. Cache or precompute the expanded run array per paragraph/layout pass instead of rebuilding it per line.
Useful? React with 👍 / 👎.
4 participants
Issue
Tracked text inserted programmatically with
editor.doc.insert(..., { changeMode: 'tracked' })was truncated in the document view when the inserted string contained newline characters (\n). Only the content before the first newline was rendered, even though the full text was preserved in comment bubbles and export.Proposed solution
Align renderer run slicing with measurer behavior for inline newlines. The renderer now expands text runs containing
\ninto text/break/text segments before slicing line ranges, so measured line indices map correctly and all multiline tracked content renders in the document.