fix(editor): selection highlight flickers when dragging across mark boundaries (SD-2024)

[tupizz]

Demo

CleanShot.2026-02-27.at.12.58.28.mp4

Summary

Fixes the selection highlight flickering/disappearing when drag-selecting across inline mark boundaries (e.g. bold → italic, colored → uncolored text).

Problem

When a user drags to select text that spans two adjacent runs with different marks (e.g., bold followed by italic), the blue selection overlay flickers — it briefly disappears for one frame, then reappears on the next pointer event. This makes drag selection feel broken on any document with mixed inline formatting.

How we debugged it

1. Reproduced in browser — loaded a complex DOCX (SuperDoc (5).docx) with mixed marks (bold, italic, colored text, tracked changes). Drag-selected across formatting boundaries and observed the highlight flash.

2. Instrumented selection monitoring — injected a 3ms-interval monitor on window.editor.state.selection to track every selection change during drag. The PM selection was stable — the flicker was purely visual, not a state issue.

3. Traced the rendering path — followed the selection overlay pipeline:

   • PresentationEditor.#updateSelectionFromEditor() reads the PM selection {from, to}
   • calls computeSelectionRectsFromDom() → DomPositionIndex.findEntriesInRange(from, to) to find DOM elements in the selection range
   • builds DOMRange objects from those elements → range.getClientRects() → draws overlay divs

4. Found the gap — when the selection boundary falls exactly on a run boundary, the PM positions land in the 2-position structural gap between adjacent text spans. Example:

   <span data-pm-start="1" data-pm-end="5">bold</span>   ← run close token at 5, open token at 6
   <span data-pm-start="7" data-pm-end="12">italic</span> ← positions 5-7 are structural tokens
   

   A selection at {from: 5, to: 7} spans only structural tokens — no text content.

5. Identified the root cause — findEntriesInRange uses half-open [start, end) semantics. For the range [5, 7):

   • Entry [1,5]: pmEnd (5) <= start (5) → excluded (boundary touch)
   • Entry [7,12]: pmStart (7) >= end (7) → excluded (boundary touch)
   • Result: zero entries → zero DOM rects → overlay cleared → flicker

Solution

Three targeted changes:

1. DomPositionIndex.findEntriesInRange — add boundaryInclusive option

Added an optional { boundaryInclusive: true } parameter that switches from half-open [start, end) to closed [start, end] overlap checks:

// Before (half-open): excludes entries touching at boundary
if (entry.pmStart >= end) break;
if (entry.pmEnd <= start) continue;

// After (inclusive): includes entries touching at boundary
if (entry.pmStart > end) break;
if (entry.pmEnd < start) continue;

This is opt-in — the default half-open behavior is preserved for all other callers.

2. DomSelectionGeometry.computeSelectionRectsFromDom — use inclusive boundaries

All calls to findEntriesInRange in the selection rect computation now pass { boundaryInclusive: true }. This ensures the two adjacent text spans are both found when a selection crosses a run boundary.

3. PresentationEditor.#updateSelectionFromEditor — safety net

If a non-empty selection (from !== to) produces zero DOM rects (edge case where even inclusive boundaries don't find entries), the method now returns early instead of clearing the overlay. This preserves the last valid highlight.

Test plan

• 4 new unit tests in DomPositionIndex.test.ts:
  • Default half-open semantics exclude boundary entries
  • boundaryInclusive includes both adjacent entries at a run gap
  • boundaryInclusive includes entry whose pmEnd equals query start
  • boundaryInclusive includes entry whose pmStart equals query end
• All 7083 super-editor tests pass
• All 1220 layout-bridge tests pass
• Manual browser test: drag-selecting across bold/italic/color boundaries no longer flickers

[linear]

SD-2024 BUG: Selection looses range around certain marks

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 389e1203b1

ℹ️ 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]

@tupizz boundaryInclusive fix looks solid — right root cause, clean API extension, good tests. left two inline comments: a stale overlay edge case worth a debug log, and a JSDoc that needs reverting to "exclusive". nothing blocking.

[caio-pizzol]

@tupizz the debugLog and the JSDoc fix look good. one thing still open — left an inline comment on the zero-rect guard.

[caio-pizzol]

@tupizz all three items from the previous rounds are addressed — the isDragging guard, the JSDoc fix, and the debugLog. the new clickToPosition refactor and isolating-boundary clamping look solid, good test coverage across the board. lgtm, approving.

[caio-pizzol]

@tupizz

one thing worth adding as a follow-up: a behavior test that reproduces the actual user interaction.

something like: 1. load a doc with mixed inline formatting (bold → italic) adjacent to a table
2. drag-select across the mark boundary
3. assert the selection range stays continuous and doesn't collapse

[harbournick]

LGTM

[superdoc-bot]

🎉 This PR is included in superdoc-cli v0.2.0-next.37

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in superdoc v1.17.0-next.42

The release is available on GitHub release

[harbournick]

🎉 This PR is included in superdoc v1.17.0

The release is available on GitHub release