SD-2570 - fix: document API tracked changes not fully rendered on document#2825
Conversation
superdoc-bot
Bot
added
review: thorough
review: careful
and removed
review: thorough
labels
![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".
caio-pizzol
left a comment
caio-pizzol
left a comment
There was a problem hiding this comment.
@chittolinag ran this in the dev app console:
await ed.doc.insert(
{ value: 'first line here\nsecond line here\nthird line here' },
{ changeMode: 'tracked' }
);text shows up, but lines 2 and 3 have no data-pm-start / data-pm-end and clicking them doesn't move the caret. sliceRunsForLine got the fix, but computeLinePmRange (contracts/src/pm-range.ts:82) and the second copy in layout-bridge/src/text-measurement.ts:315 still read un-split runs.
- restore
ParagraphMeasure.expandedRunsfrom #2824 — one source of truth for all three read-sites. - rebase:
f778c4a65added tab handling in the measurer that the helper doesn't mirror.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
You're right about I did notice a caret issue around tracked changes (might have been what you experienced). If you open a document with tracked changes and click directly on a tracked change once it's loaded, using the arrow keys won't work because the editor is not focused. So if you use up/down for example, the page will scroll up an down instead of navigating within the document (and left/right won't have any effect). This also happens with a blank document. If you open a blank document (and do not type anything, do not focus the editor) and programatically insert a tracked change, if you click it, the same behavior will happen. I am not sure if this is the issue that you faced, but that is already happening on |
caio-pizzol
left a comment
caio-pizzol
left a comment
There was a problem hiding this comment.
hey @chittolinag! thanks for last round, position fixes look clean. on the caret focus thing, repro'd here too - split it off, sgtm.
one regression this PR adds: tracked text with newlines leaves empty lines visible in original mode (and same in final for deletes). fix is small, left it inline with repro steps.
needs work.
caio-pizzol
left a comment
caio-pizzol
left a comment
There was a problem hiding this comment.
hey @chittolinag! thanks for addressing last round.
not there yet - text with both tabs and newlines renders wrong and loses content. three inline.
caio-pizzol
force-pushed
the
gabriel/sd-2570-bug-missing-content-inserted-by-ai-simplified-fix
branch
from
6da509e to
984575a
Compare
…lineNewlines The previous guard early-returned the whole iteration when a segment was empty, which also skipped the break emit and cursor advance. Leading \n, trailing \n, and consecutive \n\n inputs would drop breaks and shift pm positions downstream. Guard only the empty-text push so the break logic still runs for every \n in the source text.
caiopizzol
left a comment
caiopizzol
left a comment
There was a problem hiding this comment.
hey @chittolinag! thanks for addressing last round.
on the \t+\n you were right - doc.insert doesn't hit it (only a raw schema.text() transaction does), so it's latent drift, worth a follow-up but not a blocker.
i rebased on latest main and pushed c861628 tightening the empty-segment guard (leading and consecutive \n were dropping breaks) with tests for the edge cases.
lgtm.
caio-pizzol
deleted the
gabriel/sd-2570-bug-missing-content-inserted-by-ai-simplified-fix
branch
|
🎉 This PR is included in superdoc v1.28.0-next.16 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-cli v0.8.0-next.16 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-sdk v1.6.0-next.52 |
|
🎉 This PR is included in superdoc v1.29.0 The release is available on GitHub release |
|
🎉 This PR is included in @superdoc-dev/mcp v0.3.0-next.1 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-sdk v1.8.0-next.1 |
|
🎉 This PR is included in @superdoc-dev/react v1.2.0-next.49 The release is available on GitHub release |
|
🎉 This PR is included in vscode-ext v2.3.0-next.51 |
|
🎉 This PR is included in esign v2.6.0 The release is available on GitHub release |
|
🎉 This PR is included in template-builder v1.7.0 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-cli v0.8.0 The release is available on GitHub release |
|
🎉 This PR is included in superdoc-sdk v1.8.0 |
|
🎉 This PR is included in @superdoc-dev/mcp v0.3.0 The release is available on GitHub release |
|
🎉 This PR is included in vscode-ext v2.3.0 |
7 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.