段落中的长行内代码会让该行的正文文字不可见

[Jackbessaliuz]

检索前置
用 inline code、code invisible、inline code wrapping、markdown render、text hidden、行内代码 等 9 组关键词在仓库的 Discussions / issue 里查过，未见同类反馈。

中文版
标题：段落中的长行内代码会让该行的正文文字不可见

环境：Windows 10 / DSH 0.1.5-rc.2 / dsh web / Chromium 系浏览器（Chrome/Edge） / 深色模式

现象：当段落中出现长到必须换行的行内代码时，该行的正文文字会看不见：

文本仍在 DOM 里 —— 整段可以正常复制出来，说明内容没丢，不是数据层问题；
视觉上只有 那一段可见，同一行的其余正文消失；
拖动或选中该区域时，文字会短暂浮现；
只影响含"换行行内代码"的那一行，其下一行完全正常；短行内代码一切正常；
块级代码（``` 围栏）完全正常。
期望：含长行内代码的段落，正文文字应始终可见。

已排除的方向：起初我们怀疑是主题配色问题（自定义主题把 --dsw-alias-markdown-inline-code 调淡、导致对比度不足）。排查后排除——把该令牌恢复默认值后现象依旧，且出厂 default 主题下同样能复现，所以它与颜色无关，看起来是行内元素跨行渲染/层叠的问题。

[Jackbessaliuz]

检索前置 用 inline code、code invisible、inline code wrapping、markdown render、text hidden、行内代码 等 9 组关键词在仓库的 Discussions / issue 里查过，未见同类反馈。

中文版 标题：段落中的长行内代码会让该行的正文文字不可见

环境：Windows 10 / DSH 0.1.5-rc.2 / dsh web / Chromium 系浏览器（Chrome/Edge） / 深色模式

现象：当段落中出现长到必须换行的行内代码时，该行的正文文字会看不见：

文本仍在 DOM 里 —— 整段可以正常复制出来，说明内容没丢，不是数据层问题； 视觉上只有 那一段可见，同一行的其余正文消失； 拖动或选中该区域时，文字会短暂浮现； 只影响含"换行行内代码"的那一行，其下一行完全正常；短行内代码一切正常； 块级代码（``` 围栏）完全正常。 期望：含长行内代码的段落，正文文字应始终可见。

已排除的方向：起初我们怀疑是主题配色问题（自定义主题把 --dsw-alias-markdown-inline-code 调淡、导致对比度不足）。排查后排除——把该令牌恢复默认值后现象依旧，且出厂 default 主题下同样能复现，所以它与颜色无关，看起来是行内元素跨行渲染/层叠的问题。

补充一条观察：
被"吞掉"的似乎只是 CJK 正文，同一行里的 内容始终可见。

原文：② 特别长（用来测"溢出"这个副作用）：https://github.com/…/new?category=q-a&title=inline-code-wrapping-issue

实际渲染：行内代码（那个 URL）分两行正常显示，而它前面的中文整段不可见。

这更像层叠/遮挡而不是对比度问题 —— 若只是颜色接近，代码文字也该一起变淡；实际是 浮在上面可见、普通正文被压在下面。

另附我们的尝试：给它加 white-space: nowrap（想绕开"跨行"这个触发条件）未生效，URL 仍然换行 → 自定义 CSS 顶不过宿主规则，所以只能从宿主侧修。

[PerryLink]

你的排除配色那条是对的，而且能定位到一处确实可疑的规则：行内代码用的是 display: inline-flex，而同一个文件里的 .compact 变体用的是 display: inline + box-decoration-break: clone。

packages/client/ui-primitives/src/markdown/MarkdownText.module.css:163-174：

.markdown :not(pre) > code {
  display: inline-flex;      /* :164 */
  align-items: center;       /* :165 */
  box-sizing: border-box;
  font: var(--dsw-font-markdown-code);
  font-family: var(--ds-font-family-code);
  font-size: 0.875em !important;
  background-color: var(--dsw-alias-markdown-inline-code);   /* :170 */
  border: 0.5px solid var(--dsw-alias-border-l1);            /* :171 */
  border-radius: 6px;
  padding: 0 5px;                                            /* :173 */
}

display: inline-flex 把它变成原子行内级盒：整段代码是一个不可断的盒，而 box-decoration-break: clone 又没写，所以它既不会按行碎片化，也不会跟在正文后面续行。我在本机用 headless Chrome 把这十二行声明原样跑了一遍（Microsoft YaHei，16px/24px，300px 容器）：一段长到放不下的行内代码整体跳到下一行并撑到 50px 高（约 2.5 倍行高），getClientRects() 只返回 1 个矩形 —— 它确实从不分片。我扫了 26 种组合（2–16 个汉字 × inline-flex/inline × 300px 容器），「正文与代码共处同一行」26/26 都不成立。

但我要在这里打住：这个盒的背景盖不住正文。 按 CSS 2.2 附录 E 的绘制顺序，行内盒的背景色与边框先画、行内文字后画，同一个层叠上下文里背景永远在文字之下；我又对「短代码与正文同行」那一种排布截了图并逐像素解码，代码的底色恰好停在正文最后一个字形像素的右边（x=224 处相接），没有覆盖任何一个字形像素。所以我原来设想的「背景压住中文」是错的，不能拿它解释你看到的现象。

white-space: nowrap 为什么没生效，也就得换个解释 —— 断的不是代码里的字符，而是原子盒整体换行：整盒比剩余行宽更长时会跳到下一行，nowrap 只能阻止盒内断行（实测盒高 50px → 26px），不能让它留在正文那一行。父级 .markdown 上的 overflow-wrap: anywhere（:7）确实存在，但 overflow-wrap 在 nowrap 下本来就不生效；我也实测过把它改成 normal，盒子照样跳到下一行。另外 font-size: 0.875em !important（:169）说明宿主在这条规则上是主动加固过的，而 display 上没有 !important，所以自定义 CSS 在这一项上能赢。

要往下定位，我需要你补一个我从报告里判断不出来的区分：被吞掉的正文，是与代码同处一个行盒（同一行的左右邻居），还是代码盒上方那一行？这两者对应完全不同的机制（前者是行盒内的绘制或裁剪，后者更可能与行高和滚动容器有关），而我手上的证据只能排除「代码背景遮盖」这一种。另外，方便的话把出问题那条消息的原始 Markdown 也贴出来 —— 渲染器会把行内代码里的换行转成空格（packages/client/ui-primitives/src/markdown/render.tsx:296），所以「多行行内代码」实际是一个带空格的 <code>，这一点会影响复现。

候选修法（方向我认为是对的，但请以你的复现为准）：同一个文件的 .compact 变体已经是这么写的 ——

.compact :not(pre) > code {          /* :384-392 */
  display: inline;
  ...
  box-decoration-break: clone;        /* :391 */
}

即 display: inline + box-decoration-break: clone。.compact 是与 .markdown 挂在同一个元素上的修饰符（packages/client/ui-primitives/src/markdown/MarkdownText.tsx:197：clsx(css.markdown, variant === 'compact' && css.compact)），所以这不是「两个变体各说各话」，而是主路径少了这两条声明 —— 更像漏改，而不是有意设计。

诚实边界：我只有 headless Chrome 加这份样式表，没有你的浏览器、缩放与字体栈，也没有复现出「正文不可见」这个现象本身。上面能定下来的只有两件事：这条规则确实可疑，以及「背景遮盖」这个解释是错的。

[Jackbessaliuz]

Correction · 2026-09-23 — Root cause found: this is NOT a Harness bug. Our apologies.

The real cause was local: a third-party client plugin we had installed, dsh-smooth-stream@0.6.1. It renders assistant messages through its own markdown view (TypewriterAssistantNodeView), and its CSS module overrides the host's inline-code styling:

• .root :not(pre) > code { display: inline; … } — overriding the host's display: inline-flex
• @supports (text-box-trim: trim-both) { .root :is(p, h1…h6, blockquote) { text-box-trim: trim-both; text-box-edge: text } }

That explains every anomaly: only assistant messages reproduced (the plugin intercepts assistant rendering only), and nowrap had no effect (its white-space: normal won).

Measured on our machine (0.1.5-rc.2, Chromium): computed display: inline, getClientRects().length = 2–3 (fragmented), box-decoration-break: slice, parent overflow-x: visible. Injecting display: inline-flex !important plus text-box-trim: none !important made the swallowed CJK text reappear immediately; disabling the plugin removed the symptom entirely — along with some page sluggishness.

The Harness rule itself is fine: we compared the 0.1.5-rc.2 build against HEAD line by line and the declarations match. Closing this as resolved works for us.

Thank you, PerryLink — for pinpointing the suspect rule, for honestly retracting your own background-occlusion hypothesis, and for stating your boundaries so clearly. Our report omitted the assistant-vs-user-message distinction, which cost you a detour — sorry about that. We'll file the DOM data as an issue with the plugin author.

(This report was drafted by the two of us together — me and my AI assistant. We got the direction wrong from the start, and both feel bad about the extra round it cost you. Sorry.)