[Bug] Ordered list numbers clipped on the left edge in the web chat (Safari only)

[PhoenixQian]

[Bug] Ordered list numbers clipped on the left edge in the web chat (Safari only)

What I see

In the web UI, when an assistant message contains a Markdown ordered list, the numbers are cut vertically. Only the right half of "1.", "2.", "3." stays visible; the left half disappears. The text after the number renders normally.

Screenshot from an actual chat message:

I only see this in Safari. The same message renders correctly in Chrome.

How to reproduce

1. macOS, open the DSH web UI in Safari.
2. Ask the assistant for a reply with a numbered list, e.g. "give me a list of three points".
3. Look at the list markers in the reply.

It does not happen on every message. A page refresh usually makes the normal one reappear.

Where I think it comes from

The chat markdown styles live in packages/client/ui-primitives/src/markdown/MarkdownText.module.css:

.markdown :where(ul, ol) { padding-left: 18px; }

Top-level lists keep the default list-style-position: outside, so the marker sits right-aligned against the content edge, inside that 18px. When a message container clips horizontal overflow and the marker needs more room than 18px, the left part of the marker is cut, and there is no way to scroll it back.

The same mechanism was fixed once already, for the search results: commit e6d6e19 ("keep two-digit source markers out of the scroll clip") changed .sources padding to 2.5em for exactly this reason. That fix only covered the Search sources list. The ordered lists inside regular chat messages still use 18px.

Suggested fix

Match what was done for .sources:

.markdown :where(ul, ol) { padding-left: 2.5em; }

Alternatively, use list-style-position: inside for top-level lists (nested lists in the same file already do this). Either change gives the marker enough room, or keeps it inside the content box.

Environment

• macOS + Safari: reproduced
• Chrome: not reproduced
• DSH 0.1.x, dsh --profile web

---

[Bug] Web 聊天消息里的有序列表编号被裁掉左半（仅 Safari）

现象

Web 界面里，助手消息中 Markdown 有序列表的编号会被竖着切一刀。"1." "2." "3." 只剩下右半，左半消失；编号后面的文字完全正常。

截图来自真实聊天消息：

只在 Safari 里见到。同样的消息用 Chrome 看是正常的。

复现步骤

1. macOS 上用 Safari 打开 DSH Web。
2. 让助手给一条带有序列表的回复，例如"列三个要点"。
3. 看回复里的列表编号。

不是每条消息都会出现；刷新页面后通常会恢复。

我推测的原因

聊天消息的 markdown 样式在 packages/client/ui-primitives/src/markdown/MarkdownText.module.css：

.markdown :where(ul, ol) { padding-left: 18px; }

顶层列表沿用默认的 list-style-position: outside，编号贴着内容区右缘对齐，占这 18px 的空间。一旦消息容器在水平方向裁切溢出内容，而编号需要的位置超过 18px，编号左侧就被裁掉，且没法滚动回来。

这个机制官方之前修过一次，是搜索结果列表：commit e6d6e19（"keep two-digit source markers out of the scroll clip"），当时把 .sources 的 padding 改成 2.5em 防的正是这个。那次修复只覆盖了 Search 来源列表；聊天消息里的普通列表还是 18px。

建议的修法

和 .sources 保持一致：

.markdown :where(ul, ol) { padding-left: 2.5em; }

或者把顶层列表也改成 list-style-position: inside（同文件里嵌套列表已经是 inside）。两种改法都能让编号有足够空间，或留在内容盒内部。

环境

• macOS + Safari：可复现
• Chrome：不可复现
• DSH 0.1.x，dsh --profile web

[denial123789]

The handbook now routes this Safari-only symptom separately in v0.5.272: clipped ordered-list markers with normal text flow are a layout/overflow boundary, not evidence of a MutationObserver CPU loop. The runbook captures browser comparison, computed padding, and disposable-client regression evidence before any Session or plugin changes.\n\nGuide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/webview-mutation-observer-loop.md#route-safari-marker-clipping-separately\nRelease: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.272\n\nIndependent community documentation; the upstream repository remains the source of truth.

[argszero]

Verified against the alpha.1 tree (HEAD cd5ef81481) — your diagnosis is correct, and the fix precedent you referenced (e6d6e19) confirms the mechanism almost verbatim. The chat markdown path was simply never fixed.

1. The list rule is still unfixed

packages/client/ui-primitives/src/markdown/MarkdownText.module.css:85-88:

.markdown :where(ul, ol) {
  margin: 16px 0;
  padding-left: 18px;
}

Top-level lists keep the default list-style-position: outside, with a fixed 18px of padding. The inside remedy at :104-107 (list-style-position: inside; padding-left: 0) applies only to nested ol — top-level chat lists never got it.

2. The clip surface is real, and documented at source

packages/client/ui-conversation/src/client/skeleton/ConversationRoot.module.css:322-323 — the transcript scroller:

.scrollBody {
  overflow-y: auto;
}

…and the comment right below it states the property that matters:

"a box that scrolls in one axis computes visible to auto in the other … overflow-y: auto already made this a scroll container that clips both axes"

So an outside-position marker wider than 18px (two-digit ordinals, or line-height: 24px markers in Safari) is clipped at the inline-start edge of a scroll container that offers no way to scroll it back — your "there is no way to scroll it back" claim is exactly right. (ConversationRoot.module.css:311-313 overflow: hidden on the active-phase root is a second clip surface.)

3. Why e6d6e19 didn't cover chat

The commit (fix(ui-primitives), 2026-08-03) fixed the sources list only. Its message states the same mechanism you found:

"A scroll container clips inline-start overflow with no way to scroll it back, and ::marker is right-aligned to the content edge, so past nine sources the markers rendered as 0. and 1. where 10. and 11. belonged."

The fix sized the sources list padding in em against its own font (2.35em holds a 999. marker) and pinned it with a regression test measuring computed padding ≥ widest marker. The same treatment never landed for .markdown.

Suggested fix (follows the shipped precedent)

Replace the fixed 18px on the top-level rule with em-based room for multi-digit markers, matching e6d6e19's approach:

.markdown :where(ul, ol) {
  margin: 16px 0;
  padding-left: max(18px, 2.35em);
}

list-style-position: inside would also fix the clipping but changes how wrapped lines align (indent follows the text, not the marker), which is presumably why the nested-ol rule uses it sparingly. The em-based padding keeps the current outside-position look and matches the maintainers' own fix pattern.

One secondary Safari-specific suspect worth confirming with computed styles: li::marker { line-height: 24px } (:98-99) — a 24px marker line box inside a tighter li line box may also contribute to the vertical cut you see, on top of the horizontal clip. If that reproduces in isolation, capping marker line-height to the li's line box (or line-height: inherit) would be the companion fix.

[denial123789]

Follow-up: v0.5.288 refines the Safari diagnosis with the verified 18px outside-marker + transcript scroll-container clip boundary, the ~2.35em gutter regression path, and a separate marker line-height check. It keeps layout clipping distinct from a proven MutationObserver loop: https://github.com/sandbaseai/deepseek-harness-handbook/releases/tag/v0.5.288