Selection highlight trails the selection: the previous highlight stays painted, and on a two-column paragraph it covers both columns

[Nathaniel-260]

What happened?

The selection highlight trails the selection. When an existing selection is replaced by a new one, the previous highlight stays painted for a noticeable moment before the new one appears.

On a paragraph that flows across two columns this is not a cosmetic delay, because the stale highlight covers both columns. Selecting the paragraph and then dragging inside one column shows the whole paragraph — including the column the pointer is not in — lit up, and only afterwards does it shrink to the column that was actually dragged in. To a user that reads as "dragging in one column selected the other column too, and then it corrected itself".

The selection itself is never wrong. doc.selection.current() reports exactly the intended range throughout, the exported document is correct, and the end state on screen is correct. It is only the highlight that arrives late.

The same lag shows up without columns at all: after a double click or a triple click there is a stretch where nothing is highlighted before the selection paints.

Steps to reproduce

1. New document. Layout → Columns → Two.
2. Type or paste a single paragraph long enough to flow from the first column into the second on the same page.
3. Triple click inside the paragraph, in the first column. The whole paragraph highlights, across both columns — this is correct, the paragraph really is in both.
4. Now press inside the first column and drag a short distance, staying inside that column the whole time.

Observed: the both-column highlight from step 3 stays on screen; then the page goes unhighlighted; then the correct single-column highlight appears. Expected: the old highlight goes away with the new press, or the new one replaces it directly.

The bigger the document, the longer the middle state lasts. The user who reported this to us was working on a real Hebrew document — considerably larger than a synthetic fixture — and described it as roughly a second of "everything is selected".

SuperDoc version

2.13.0

Browser

Chrome

Additional context

This came out of verifying #3952. The column work there is fixed and behaves correctly in every gesture we tried, including the blank-area drag and Shift+ArrowDown across the column boundary — thank you for that. This one looks orthogonal to the column arbitration: the model is right and the paint trails it, and columns only make it conspicuous because a stale highlight can then span the gutter.

I have not established whether this predates 2.13.0, so I am deliberately not filing it as a regression. I do have timings from an instrumented run, and I am happy to send those to you privately if they would be useful.

[Nathaniel-260]

@jelkes1 thank you — and thank you to the whole team. I keep saying it because it keeps being true: the pace and the care in this repo are not what one expects as a person filing bug reports.

Two things on this one.

There is no PR from me on this one, and it is not for lack of looking. For the other layout issues I could point at the code and send a patch; here I cannot reach it from outside. On main (2.13.0-next.11) the only selection-overlay renderer in the open tree is CursorRenderer in packages/layout-engine/layout-bridge/src/cursor-renderer.ts, and git grep finds it only in its own file, in the layout-bridge barrel export, and in its own test — nothing in production code constructs it. The superdoc__selection-layer in SuperDoc.vue is the comments highlight and is gated on isCommentsEnabled, so it is not that either. So the highlight that trails here is painted inside @superdoc/docx-engine, which is yours and not mine.

One constructive note from that same open file, because it may be the shortest description of what this issue is actually asking for. CursorRenderer.renderSelection() keeps the overlay divs it already has, adds or removes only the difference in count, and then repositions them. It therefore never passes through a frame with no highlight at all, and never leaves a stale rectangle standing while a new one is being worked out. If the engine's overlay instead clears on the new press and repaints once the new rects are measured, that would produce exactly the three-state sequence in the report — old highlight, nothing, correct highlight. I cannot see the engine's implementation, so please treat that as a description of the symptom's shape and not a diagnosis. But if the new rects genuinely are only available after a layout pass, then holding the old ones up until they arrive would at least remove the "nothing is selected" gap in the middle, which is the part a user reads as a bug rather than as slowness.

And a personal note. I did say I would stop opening issues. I lasted about a day, so evidently I am not to be trusted on that. But I am honestly relieved that this particular one is not patchable from the outside: with two cores and coursework, the hours that a proper fix-and-verify cycle costs me are better spent on my degree, and this one could not be in better hands.

Thank you for everything. Your success here is my success too — the documents I am writing depend on it.

[caio-pizzol]

@Nathaniel-260 we’ve now reproduced the highlight delay on our side and logged it for engineering. We haven’t confirmed the cause yet, but we have enough to continue investigating without another test run from you. Thanks for the detailed report—we’ll follow up here when we have an update.