bug(desktop): composer caret appears as a tiny mark after switching conversations from WorkHub

[sunrioa]

What happened

After navigating through WorkHub and switching conversations in the sidebar, the insertion caret at the start of the empty conversation composer appears as a tiny dot or short segment above the placeholder, instead of a full-height caret.

The placeholder is “描述任务，@ 引用文件，/ 选择技能…”. The problem concerns the text insertion caret, not the mouse pointer or an agent activity indicator.

Expected: when the empty composer is focused, the insertion caret should be fully visible alongside the placeholder.

How to reproduce

The reporter observed the following sequence:

1. Open Desktop with several existing conversations and enter WorkHub.
2. Click a task card in the horizontal row at the top of WorkHub.
3. Click a conversation in the left sidebar, then switch between sidebar conversations twice in succession. The repeated action is the sidebar switching, not the entire WorkHub sequence.
4. Focus the empty conversation composer and inspect the caret before the placeholder.

The reporter reproduced the visual problem on macOS and initially observed it on Windows. The exact timing requirement and reproduction rate have not yet been established.

Environment

• Maka Desktop: 0.2.0, source baseline d2e6c1f273b7daa23ff75b84c8a30dca3f316713.
• macOS: 26.5.2, arm64.
• Electron dependency: 43.4.1.
• UI dependency: @astryxdesign/core 0.5.2.
• Also reported on Windows; Windows version has not been collected.
• The local checkout contains separate provider-request diagnostic changes. No composer or WorkHub code was changed for this investigation; this is not yet a clean-checkout reproduction.

Logs, screenshots, or additional context

The cause is not established: clipping, caret geometry, and selection restoration are investigation candidates, not confirmed diagnoses. Code inspection found draft-selection restoration in packages/ui/src/composer.tsx; the existing focus/selection unit tests do not establish the visual caret height in Electron.

Related but not known duplicates: #4827 / #4836 concern caret position after changing thinking level; #4602 addresses restored drafts taking focus. None establishes a fix for this reported visual symptom.

Draft prepared with OpenAI Codex from the reporter's reproduction steps and screenshots, local code inspection, and issue/PR searches. Independent automated reproduction has not been established.

Screenshot

The insertion caret immediately before “描述任务” is visible only as a short mark above the placeholder, rather than a full-height vertical line.

[sunrioa]

Follow-up investigation, prepared with OpenAI Codex:

The empty-editor height collapse is still reproducible in a browser component
probe built from current main, 0d4a6ba5f48de6807ab96d6b5aad3635cc6a1f57.
This used a separate checkout with no tracked source modifications, only an
added diagnostic story; installed dependencies were reused with the same
lockfile and existing Astryx patch.

The reduced sequence uses the real Maka Composer and ChatSurfaceLayout:

1. Mount an empty editor.
2. Set its ancestor to inert, then hide its owning frame.
3. Show the frame while still inert.
4. Remove inert.

The editable's height changes from 30px to 8px and remains 8px after step 4.
Its line height is 22px and vertical padding is 4px per side, so the remaining
height is entirely padding. Directly mounting the project's installed/patched
Astryx ChatComposerInput 0.5.2 produces the same result; no model request or
Electron-specific window behavior is needed for this reduced reproduction.

For both components, the same geometry check fails without a minimum-height
guard, passes with a temporary min-height: calc(1lh + 8px), and fails again
after removing the guard and repeating with freshly mounted editors.

A candidate fix is to ensure the actual scrolling contenteditable has a minimum
size of one line plus its vertical padding, while preserving inert and editor
identity. The padding must be accounted for rather than hard-coding 30px:
compact WorkHub currently uses 6px per side.

This narrows the layout failure but does not establish a Chromium engine root
cause or a production-ready fix. The full native navigation sequence on this
latest commit, Windows, compact WorkHub and real IME regression coverage are
still outstanding. The browser catalog built and the geometry probe ran;
this is not a claim that the full test/typecheck suite passes.

[sunrioa]

take