Prevent duplicate text cursors in the composer

[open-design-crew]

Summary

Two text cursors can appear on the canvas/composer area at the same time.

Current behavior

In the design-system extraction flow, the UI can show two visible insertion cursors simultaneously: one near the start of the composer text and another near the end of the visible text. This makes it look like two text fields or editing states are focused at once.

Expected behavior

Only one insertion cursor should be visible for the active text input. The composer/canvas should have a single focused editing target, and stale or duplicated caret rendering should be cleared when focus or text layout changes.

Steps to reproduce

1. Open a design-system extraction flow.
2. Focus the composer input with existing prompt text.
3. Observe the text entry area.
4. Intermittently, two carets appear in the same input/canvas region.

Notes

A screenshot was provided showing two visible carets in the input area: one at the beginning of the prompt text and one near the right side of the same row.

Why this matters

Duplicate cursors make the editing state ambiguous. Users may not know where typing will be inserted, and it makes the composer feel visually broken.

[lefarcen]

Hey @open-design-crew[bot] — thanks for surfacing this. I checked the current composer path, and this doesn’t look like the old textarea/highlight-overlay mismatch from #3392: the design-system extraction workspace now goes through the Lexical-based ChatComposer / LexicalComposerInput, while the async mention ordering fix in #4189 only covered the skill-insert path.

So for this repro — focusing an existing prompt and intermittently seeing one caret near the start plus another near the live insertion point — the more likely lane is a fresh render/focus regression in the current Lexical composer path for the design-system workspace, not a straight duplicate of the earlier mention-drift bugs.

Related prior art for anyone picking this up:

• visible text cursor/caret is not aligned with the actual insertion/edit position #3596 tracked the earlier visible-caret vs real-insert-position drift.
• PR fix(web): insert skill mention before the async project patch #4189 fixed the async skill-mention insertion ordering that could drop the selection.
• PR fix(web): align chat composer caret with the mention highlight overlay #3392 fixed the pre-Lexical overlay alignment bug.

Keeping the current labels as-is for now. If we can confirm this also reproduces in a regular project chat (not just the design-system extraction flow), that’ll tell us whether the regression is in the shared composer itself or in the route-specific mounting around that workspace.

[lefarcen]

If anyone wants to take this on, comment /claim and we’ll assign it your way.
The earlier caret-fix links above should give you a solid starting point.

[costajohnt]

/claim

Thanks for the prior-art links. I'll start by pinning down whether it reproduces in a regular project chat or only the design-system extraction flow, so we know if it's the shared Lexical composer or the route-specific mounting.

[lefarcen]

Hey @costajohnt — appreciate you picking this up. Starting by narrowing shared-composer vs route-specific repro is exactly the right first cut.

Quick time check so I can pace follow-up sanely: roughly how long do you think this’ll take — a few hours, 1–3 days, ~1 week, or longer?

[costajohnt]

A few hours, and it turned out to be the shorter end of that: PR is up.

It's the shared composer, not route-specific. The caret-color on the editable is global, so any empty+idle composer running the placeholder carousel gets the native caret blinking at offset 0 on top of the carousel's own decorative caret. The design-system follow-up is just one route that feeds the carousel scenarios; the home hero has the identical flaw, so the fix is one CSS rule keyed off the carousel being a sibling of the editor, covering both.

[lefarcen]

Quick heads-up: @costajohnt has opened PR #5393 for this. The current fix narrows the repro to the shared composer path rather than the design-system route wrapper — it hides the native browser caret only while the placeholder carousel is mounted, so the decorative carousel caret is the only one visible in the empty/focused state. Keeping this issue open until that PR lands and the fix is verified.