apache / apache/maka

bug(ui): long default system notes are clipped at both edges

Open
#5,138 1 comment 0 reactions 0 assignees View on GitHub
bug
Dominant language
TypeScript
Stars
5.4k
Forks
502
Avg merge
1d 2h
Merged PRs (30d)
715

Description

## What happened

Long `system_note` diagnostics in the Desktop transcript are rendered as a single centered, non-wrapping line. When the text is wider than the chat reading measure, both ends overflow and are clipped, so the user can read only the middle of the message.

The reported zh-CN screenshot contains two separate affected notes. Their complete source copy begins and ends as follows:

```text
供应商在丢弃或改写上下文:... 让 Maka 先行压缩。
本次交换用了约 129127 tokens,... 若希望回复保持完整,可调大窗口。
```

In the rendered transcript, the first visible line starts around `改写上下文` and ends around `让 Ma`; the second starts around `用了约 129127` and loses its ending. There is no horizontal scrollbar or other way to reveal the omitted text.

This is separate from #5137. That issue tracks the incorrect remediation inside `context_provider_dropping`; this issue tracks the shared rendering behavior that makes long default system notes unreadable regardless of their semantics.

Expected: diagnostic system notes remain fully readable at the normal Desktop reading measure and at narrower widths. Long notes should wrap within the available width without horizontal scrolling or clipped prefixes/suffixes. Short divider-style status notes should keep their existing presentation.

## How to reproduce

1. Open a Desktop conversation using the `zh-CN` locale.
2. Reach a turn that records `context_provider_dropping` and/or `context_window_overrun`, or render either current localized string as a default `ChatSystemMessage` inside the normal 800 px chat reading measure.
3. Inspect the transcript.

Observed: the note stays on one centered line and both ends are clipped.

The rendering chain on current main is deterministic:

- `packages/ui/src/materialize.ts` materializes these records as ordinary visible system notes.
- `packages/ui/src/chat-turn.tsx` sends non-compaction notes to `ChatSystemMessage` with `variant="default"`.
- Astryx `ChatSystemMessage` centers its contents and gives the default content span `display: inline-flex`, `flex-shrink: 0`, and `white-space: nowrap`.
- Astryx `ChatLayout` sets `overflow-x: hidden` on the scrollable transcript root.
- Maka constrains a turn to `--maka-reading-measure: 800px`.

Together, these rules create an oversized unshrinkable line centered inside a narrower container, then hide the overflow on both sides. The short `context_compacted` divider visible in the same screenshot is unaffected because it uses the separate `divider` variant and fits within the measure.

## Environment

- Maka commit: `a9b4f21afb17e0ef310d076382e69ddda3a441d7`
- OS: Ubuntu Linux x86_64, kernel `7.0.0-30-generic`
- Surface: Desktop
- Locale: `zh-CN`
- Node.js: `v26.3.0`

## Logs, screenshots, or additional context

No overlapping open issue or PR was found using searches for `system note clipped`, `system message overflow`, and `system note nowrap`.

Suggested regression coverage:

- a long zh-CN default system note at the standard Desktop reading measure;
- a long English default system note and a narrower responsive width;
- assertions that the full prefix and suffix are reachable/readable and that no horizontal scroll is required;
- preservation of the current short default and divider presentations.

Contributor guide

Open the contributing guide

Research direction

Read packages/ui/src/materialize.ts and packages/ui/src/chat-turn.tsx, then trace the default ChatSystemMessage through Astryx’s ChatLayout and message styling. Reproduce with the long zh-CN and English notes at 800px and a narrower width. Done means long default notes wrap with complete prefixes and suffixes, require no horizontal scrolling, and short default and divider presentations remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
desktop, frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.