fix(super-editor): anchor header/footer caret to the line box after a tab - #3870
Merged
caio-pizzol merged 4 commits intoAug 10, 2026
Merged
Conversation
Caret paths each decided independently whether an element's own box or its enclosing line box is the caret box. A tab span and an empty SDT placeholder are painted with a box that is deliberately not the line box, so reading the element's own rect puts the caret off its row. Move that rule into dom-observer/CaretLineAnchoring.ts and route the body caret path through it, so a new caret path gets the rule by construction rather than by remembering a comment. No behavior change.
… tab Typing in a header or footer and pressing Tab rendered the caret about 5.5px below its own line, hanging past the bottom of the row. Typing any character snapped it back, so the insertion point was always correct - only the caret's painted position between the Tab and the next keystroke was wrong. A painted tab span is deliberately height: line.lineHeight with vertical-align: bottom (SD-3330) inside a .superdoc-line carrying font-size: 0, so its own border box starts below the line top. computeCaretRect resolves through #computeVisibleSurfaceCaretRect, which falls back to the element's own rect for entries with no child text node. A tab span is painted empty, so it took that branch and handed the tab's box to the caret as both y and height. Same symptom as superdoc#3507, which superdoc#3677 fixed for body text. That fix only touched DomSelectionGeometry, so the header/footer path never got it. Refs superdoc#3507, superdoc#3677
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
caio-pizzol
approved these changes
Aug 10, 2026
Contributor
There was a problem hiding this comment.
Thanks for the fix, @PopaSerban! I reproduced the bug and confirmed this PR fixes it. The code and tests look good.
Approving - the failing CI check is unrelated.
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.
PR description:
Typing in a header or footer and pressing Tab renders the caret about 5.5px below its own line, hanging past the bottom of the row. Typing any character snaps it back, so the insertion point was always correct — only the caret's painted position between the Tab and the next keystroke was wrong.
This is the same symptom as #3507, which #3677 fixed for body text in June. That fix only touched
DomSelectionGeometry.ts, so the header/footer caret path never got it.Refs #3507, #3677
before.mov
after.mov