fix(cli): fill content area background on wrapped input lines

[lcheng321]

What this PR does

Adds backgroundColor={theme.background.primary} to the input content container (<Box flexGrow={1} flexDirection="column">) in BaseTextInput.tsx, so the whole input area paints one continuous background — including the trailing empty cells that appear on wrapped or multi-line input.

Why it's needed

Ink only paints the terminal cells that actually contain text. The content container <Box> had no backgroundColor, so the trailing empty cells on any wrapped/multi-line input fell through to the terminal's default background, leaving a visible gap in the input box. Setting a backgroundColor makes Ink flood-fill the box's entire computed layout area before drawing children, covering all empty cells regardless of wrap mode. Reported in #5562.

Reviewer Test Plan

How to verify

1. Launch the interactive TUI (npm run dev, or a built qwen).
2. In the bottom input box, type a single line long enough to soft-wrap, or paste multi-line text.
3. Observe the background of the input content area across every visual line.

Expected (after this PR): the background color fills the entire input area continuously, with no gaps on wrapped/extra lines. Before: trailing empty cells on wrapped lines show the terminal's default background, breaking the box visually.

Evidence (Before & After)

Before — from #5562 (red arrows mark the discontinuity):

After — author capture pending; expected result is the gap-free, continuously-filled input background described above. (Reformatted to the template by a maintainer — I did not run the TUI locally, so I'm not attaching a fabricated "after".)

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

N/A — a single rendering-prop change with no runtime/sandbox specifics.

Risk & Scope

• Main risk or tradeoff: purely visual. The new backgroundColor reuses the existing theme.background.primary token (already used across components like PermissionsDialog, StatsDialog, PrepareLabel), so it tracks the active theme rather than hard-coding a color.
• Not validated / out of scope: local before/after visual capture across all three platforms (the Ink rendering path is platform-agnostic).
• Breaking changes / migration notes: none.

Linked Issues

Fixes #5562

中文说明

这个 PR 做了什么

在 BaseTextInput.tsx 的输入内容容器（<Box flexGrow={1} flexDirection="column">）上增加 backgroundColor={theme.background.primary}，使整个输入区域绘制为连续的背景色 —— 包括换行或多行输入时出现的行尾空白单元格。

为什么需要它

Ink 只会绘制真正包含文字的终端单元格。内容容器 <Box> 此前没有设置 backgroundColor，因此换行/多行输入的行尾空白单元格会"漏"到终端默认背景，导致输入框出现可见的断裂。设置 backgroundColor 后，Ink 会在绘制子元素之前用该背景色铺满整个盒子的布局区域，无论是否换行都能覆盖所有空白单元格。问题见 #5562。

Reviewer 验证步骤

如何验证

1. 启动交互式 TUI（npm run dev，或已构建的 qwen）。
2. 在底部输入框输入一段足够长、会自动软换行的单行文本，或粘贴多行内容。
3. 观察输入内容区域在每一行上的背景色。

期望（本 PR 之后）：背景色连续铺满整个输入区域，换行/多出来的行上没有空洞。修复前：换行行的行尾空白单元格显示为终端默认背景，视觉上割裂。

证据（前 & 后）

修复前 —— 来自 #5562（红色箭头标出断裂处）：

修复后 —— 作者截图待补；预期是上文所述连续、无空洞的输入框背景。（描述由维护者按模板重排 —— 我没有在本地实跑 TUI，因此不附伪造的"修复后"截图。）

测试平台

系统	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	⚠️

运行环境（可选）

N/A —— 仅一处渲染属性改动，无运行时/沙箱相关。

风险与范围

• 主要风险或权衡：纯视觉改动。新增的 backgroundColor 复用既有的 theme.background.primary 主题令牌（PermissionsDialog、StatsDialog、PrepareLabel 等组件均已使用），因此跟随当前主题而非硬编码颜色。
• 未验证 / 范围之外：三个平台的本地前后视觉截图（Ink 渲染路径与平台无关）。
• 破坏性变更 / 迁移说明：无。

关联 Issue

Fixes #5562

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

Thanks for the PR, @lcheng321! 👋

Before we dive into the code, this needs a quick pass against the PR template. A few required sections are missing:

• Reviewer Test Plan — the most important one. Right now there's no reproduction steps, no Before/After evidence (tmux capture, screenshots, or recording), and no "Tested on" OS matrix. For a TUI rendering fix like this, a side-by-side Before/After of the wrapped input lines is exactly what reviewers need to approve.
• Risk & Scope — even for a one-line fix, note the risk (e.g. "only affects wrapped input rendering; no breaking changes").
• Linked Issues — the body says Fixes #5562 inline but should use the Linked Issues section so GitHub auto-closes it.
• 中文说明 detail block — required for bilingual review.

Once the template is filled in, happy to re-run triage. 🙏

中文说明

感谢 @lcheng321 的 PR！👋

在开始代码评审之前，需要先按 PR 模板 把几个必填部分补齐：

• Reviewer Test Plan：这是最关键的一块。目前缺少复现步骤、Before/After 证据（tmux 截图、录屏或截图均可）、以及"Tested on"操作系统矩阵。对于这类 TUI 渲染修复，评审人最需要看到的就是换行输入前后效果的并排对比。
• Risk & Scope：即使只是一行改动，也请写明风险（例如"仅影响输入框换行渲染，无破坏性变更"）。
• Linked Issues：正文里写了 Fixes #5562，但请放到 Linked Issues 区块，GitHub 才会自动关闭 issue。
• 中文说明 折叠块：双语评审必需。

模板补齐后，会重新跑 triage。🙏

— Qwen Code · qwen3.7-max

[wenshao]

No issues found. LGTM! ✅ Downgraded from Approve to Comment: CI still running (22 checks pending).

— qwen3.7-max via Qwen Code /review

[wenshao]

@qwen-code /triage

[qwen-code-ci-bot]

Thanks for the PR, @lcheng321!

Template looks good ✓ — all sections present, bilingual, linked to #5562.

On direction: this is a straightforward rendering bug fix. User-reported in #5562 — input box background color has visible gaps on wrapped lines. Purely cosmetic, no risk of breaking anything else. Well within the project's UI polish mission. Claude Code's CHANGELOG has similar entries ("full-width background highlight" fixes), confirming this is a legitimate concern for terminal UI tools.

On approach: this is about as minimal as it gets — one prop addition on an existing <Box>. The theme.background.primary token is already used across 7+ components (PermissionsDialog, StatsDialog, ConversationMessages, PrepareLabel, Help, etc.), so it's consistent with the existing theme system. No new abstractions, no scope creep. The fix makes Ink flood-fill the box's computed layout area before drawing children, which is exactly the right approach for this kind of gap.

Moving on to code review. 🔍

中文说明

感谢 @lcheng321 的 PR！

模板完整 ✓ — 所有章节齐全、双语、关联 #5562。

方向：这是一个很直接的渲染 bug 修复。用户 #5562 报告输入框换行时背景色有可见断裂。纯视觉问题，不会破坏其他功能。完全属于项目 UI 打磨的范畴。Claude Code 的 CHANGELOG 也有类似的"全宽背景高亮"修复记录，说明终端 UI 工具关注这类问题是合理的。

方案：改动极小 — 只在现有 <Box> 上加了一个 prop。theme.background.primary 主题令牌已在 7+ 个组件中使用（PermissionsDialog、StatsDialog、ConversationMessages、PrepareLabel、Help 等），与现有主题体系一致。没有新增抽象，没有范围蔓延。该修复让 Ink 在绘制子元素前先铺满盒子的布局区域，正是解决此类空洞问题的正确做法。

进入代码审查 🔍

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Code Review

The diff is a single-line addition of backgroundColor={theme.background.primary} to the content container <Box> in BaseTextInput.tsx. No concerns:

• The theme import is already present at line 28 (import { theme } from '../semantic-colors.js')
• backgroundColor is a standard Ink <Box> prop — no custom rendering logic needed
• The token theme.background.primary resolves to the theme's dark background (RGB 30,30,46 in the default theme), matching the surrounding input area
• No other files are affected; BaseTextInput is shared by InputPrompt and AgentComposer, so both benefit from the fix
• No regressions: the prop only adds background painting, doesn't change layout, sizing, or event handling

Tmux Testing

Tested via bundled build with the PR change applied. capture-pane -e captures ANSI escape sequences to verify background color behavior.

Before (installed v0.18.5 — bug present)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> This is a very long line of text that should wrap around in the input box to test whether the
  background color fills the entire area continuously without any gaps on wrapped lines 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

ANSI escape analysis (line 12–13 of input area):

^[[38;2;203;166;247m> ^[[39mThis is a very long line of text that should wrap around in the input box to test whether the
  background color fills the entire area continuously without any gaps on wrapped lines^[[7m ^[[0m

No ^[[48 background color codes — text uses only foreground color (^[[38). Trailing empty cells on wrapped lines fall through to the terminal's default background, confirming the gap.

After (this PR — bundled build with fix)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
* This is a very long line of text that should wrap around in the input box to test whether the background color fills the entire area continuously without any gaps on wrapped
  lines 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

ANSI escape analysis (input area):

* ^[[39m^[[48;2;30;30;46mThis is a very long line of text that should wrap around in the input box to test whether the background color fills the entire area continuously without any gaps on wrapped
^[[49m  ^[[48;2;30;30;46mlines^[[7m ^[[0m^[[48;2;30;30;46m                                                                                                                                                                                               ^[[49m

^[[48;2;30;30;46m (background color) is present on both the first and wrapped lines. The trailing spaces after the text also carry the background color, filling the entire width. ^[[49m correctly resets after the painted area. The fix works as intended.

中文说明

代码审查

Diff 仅在 BaseTextInput.tsx 的内容容器 <Box> 上新增 backgroundColor={theme.background.primary} 一个属性。无问题：

• theme 已在第 28 行导入
• backgroundColor 是 Ink <Box> 的标准 prop，无需自定义渲染逻辑
• theme.background.primary 解析为主题深色背景（默认主题 RGB 30,30,46），与输入区域周围一致
• 不影响其他文件；BaseTextInput 由 InputPrompt 和 AgentComposer 共用，两者均受益
• 无回归风险：该属性仅增加背景绘制，不改变布局、尺寸或事件处理

Tmux 测试

通过打包构建（bundled build）应用 PR 改动进行测试。capture-pane -e 捕获 ANSI 转义序列以验证背景色行为。

修复前（已安装 v0.18.5）： 无 ^[[48 背景色转义码 — 文本仅使用前景色。换行行的尾部空白单元格落入终端默认背景，证实了断裂问题。

修复后（本 PR）： ^[[48;2;30;30;46m 背景色在第一行和换行行上均存在。文本后的尾部空格也带有背景色，填满整个宽度。^[[49m 在绘制区域后正确重置。修复效果符合预期。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

Reflection: this is a textbook minimal fix. One prop, one line, zero new abstractions. The problem is real (user-reported with screenshot), the root cause is well-understood (Ink doesn't paint background on empty cells unless backgroundColor is set on the container), and the solution uses the existing theme system consistently with 7+ other components.

My independent proposal for this bug would have been exactly what this PR does — set backgroundColor on the content <Box>. There's no simpler path, and the PR didn't miss anything.

The ANSI escape sequence evidence is conclusive: before the fix, no ^[[48 codes appear on input lines; after the fix, ^[[48;2;30;30;46m fills both the text-bearing and empty cells across all visual lines. The trailing-space fill is particularly important — it's what eliminates the visible gaps.

One minor note: the PR's "Tested on" table has all three platforms marked ⚠️ (not tested). For a pure rendering-prop change, this is low-risk — Ink's background painting is platform-agnostic — but a quick visual confirmation from the author on at least one platform would be ideal. Not a blocker.

Ship it. ✅

中文说明

反思：这是一个教科书式的最小修复。一个属性、一行代码、零新抽象。问题是真实的（用户带截图报告），根因理解清晰（Ink 不在容器上设置 backgroundColor 时不会绘制空白单元格的背景），方案使用现有主题体系，与 7+ 个其他组件保持一致。

如果让我独立提出修复方案，结果会和本 PR 完全一样 — 在内容 <Box> 上设置 backgroundColor。没有更简单的路径，PR 也没有遗漏任何东西。

ANSI 转义序列证据确凿：修复前无 ^[[48 码出现在输入行上；修复后 ^[[48;2;30;30;46m 填满了所有视觉行上的文本单元格和空白单元格。尾部空格填充尤为关键 — 正是它消除了可见断裂。

小提醒：PR 的"测试平台"表三个系统都标了 ⚠️（未测试）。对于纯渲染属性改动风险很低 — Ink 的背景绘制与平台无关 — 但作者最好能在至少一个平台上做快速视觉确认。不构成阻塞。

可以合并 ✅

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

LGTM, looks ready to ship. ✅

[wenshao]

🔬 Maintainer verification — local build + real-TUI A/B

I built this PR from source in an isolated worktree and ran a deterministic before/after on the real qwen binary. The change works exactly as described. Two points are worth a conscious merge decision (findings #3–#4 below).

How it was verified

• Build: git worktree off pr-5568 (= origin/main + this single line). npm ci && npm run build → clean (exit 0). Change confirmed present in packages/cli/dist/....
• Real-TUI A/B: tmux, 100 columns, Default dark theme (so theme.background.primary = #1E1E2E). Typed a 144-char no-space string so it soft-wraps into 2 visual lines, then tmux capture-pane -e to read the real SGR (color) bytes. The PRE-FIX binary was built by reverting the one line + rebuilding @qwen-code/qwen-code (dist re-checked to confirm the mutant). Same theme / width / keystrokes — the only variable is this 1-line change.

Evidence — the wrapped continuation line (visual line 2)

theme.background.primary SGR = ESC[48;2;30;30;46m. Occurrences across the whole screen: PRE-FIX → 0, FIXED → 3.

PRE-FIX (current main):
  pTEST_…wrapTEST_ ESC[7m␠ESC[0m         ← line ends at the cursor; trailing cells unpainted (terminal default)

FIXED (this PR):
ESC[49m  ESC[48;2;30;30;46mpTEST_…wrapTEST_ESC[7m␠ESC[0mESC[48;2;30;30;46m              ESC[49m
                                                         └─ trailing empty cells flood-filled #1E1E2E ─┘

So Ink's renderBackground now flood-fills the content box's full rectangle (children paint on top) → the wrapped line's trailing cells carry the theme background. ✅ Core claim verified at the byte level. (In plain capture-pane the two are identical — as expected for a color-only change.)

Findings

1. ✅ Correct & minimal. Mechanism confirmed in ink/render-background.js (fills contentWidth × contentHeight, then renders children over it). No behavioral change: existing BaseTextInput (3/3) + InputPrompt (171/171) tests pass.
2. ✅ Safe on every theme. For the No Color theme (and any theme where background.primary is ''), both colorize and renderBackground short-circuit on the falsy color → no fill, identical to today. No crash / no stray escape codes.
3. ⚠️ It introduces a background rather than patching a gap in an existing one. On current main (and at the reporter's v0.18.4) BaseTextInput / InputPrompt / the app root set no backgroundColor — the composer is fully transparent, so wrapped lines are uniformly terminal-colored and there is no discontinuity reproducible from current code in a default setup. The lighter band in bug(cli): 输入框换行时背景色渲染不连续 #5562's screenshot is not painted by the composer code at that revision, so it most likely comes from the reporter's environment (terminal text-selection highlight / screenshot artifact, or a non-default config). This PR gives the composer a solid theme.background.primary fill that is correctly continuous across wraps.
4. ⚠️ Design tradeoff to decide consciously. This makes the composer the only filled box in the TUI (the header and other framed areas stay transparent). If the user's terminal background matches the active theme (the intended pairing) the fill is invisible and seamless. If it differs, the composer now renders as a visibly distinct colored rectangle. → Worth shipping if a solid composer background is the desired aesthetic.
5. 📝 Minor doc nit: the description says theme.background.primary is "already used across components like PermissionsDialog, StatsDialog, PrepareLabel." Those reference the token as a foreground color on an accent background (inverted text), not as a Box backgroundColor. After this PR, BaseTextInput is the first and only place using theme.background.primary as a Box background.
6. 📝 No test added; the 3 existing BaseTextInput tests cover keypress/paste only. A regression test (assert the wrapped-line frame carries the bg SGR on trailing cells) is feasible with ink-testing-library.

Recommendation

Safe to merge — correct, low-risk, no regressions, graceful on every theme — if the project wants the composer to read as a solid theme-colored box (finding #4). Non-blocking, optional: add a small regression test and tidy the "reuse" wording in the description.

🇨🇳 中文版（完整对应）

🔬 维护者验证 —— 本地构建 + 真实 TUI A/B

我在独立 worktree 中从源码构建了本 PR,并对真实 qwen 二进制做了确定性的前后对比。改动与描述完全相符。 有两点值得在合并时有意识地决策(下方发现 #3–#4)。

验证方法

• 构建:基于 pr-5568(= origin/main + 这一行)开 git worktree。npm ci && npm run build → 干净(exit 0)。改动确认存在于 packages/cli/dist/...。
• 真实 TUI A/B:tmux,100 列,Default 深色主题(故 theme.background.primary = #1E1E2E)。输入 144 个无空格字符使其软换行成 2 个可视行,然后 tmux capture-pane -e 读取真实的 SGR(颜色)字节。PRE-FIX 二进制通过还原这一行 + 重新构建 @qwen-code/qwen-code 得到(dist 已复查确认 mutant)。主题/宽度/按键完全一致,唯一变量就是这 1 行改动。

证据 —— 换行续行(可视第 2 行)

theme.background.primary 的 SGR = ESC[48;2;30;30;46m。整屏出现次数:PRE-FIX → 0,FIXED → 3。

PRE-FIX(当前 main):
  pTEST_…wrapTEST_ ESC[7m␠ESC[0m         ← 行在光标处结束;行尾单元格未着色(终端默认背景)

FIXED(本 PR):
ESC[49m  ESC[48;2;30;30;46mpTEST_…wrapTEST_ESC[7m␠ESC[0mESC[48;2;30;30;46m              ESC[49m
                                                         └─ 行尾空白单元格被铺满 #1E1E2E ─┘

即 Ink 的 renderBackground 现在会铺满内容盒子的整个矩形(子元素绘制在其上)→ 换行行的行尾单元格带上了主题背景。✅ 核心主张在字节级得到验证。(在不带颜色的 capture-pane 中两者完全相同 —— 对纯颜色改动符合预期。)

发现

1. ✅ 正确且精简。 机制在 ink/render-background.js 中确认(填充 contentWidth × contentHeight,再把子元素绘制在上面)。无行为变化:既有 BaseTextInput(3/3)+ InputPrompt(171/171)测试全过。
2. ✅ 对所有主题安全。 对 No Color 主题(以及任何 background.primary 为 '' 的主题),colorize 和 renderBackground 都会对 falsy 颜色短路 → 不填充,与现状完全一致。不崩溃 / 不残留转义码。
3. ⚠️ 这是引入一个背景,而非补既有背景的空洞。 在当前 main(以及 reporter 的 v0.18.4)上,BaseTextInput / InputPrompt / app 根都没有设置 backgroundColor —— 输入框完全透明,因此换行行是统一的终端背景色,默认配置下从当前代码无法复现那种断裂。bug(cli): 输入框换行时背景色渲染不连续 #5562 截图里那条更亮的色带并非该版本的输入框代码所绘制,因此它很可能来自 reporter 的环境(终端文本选区高亮 / 截图工具痕迹,或非默认配置)。本 PR 给输入框加了一个实心 theme.background.primary 填充,且在换行处正确连续。
4. ⚠️ 需有意识决策的设计权衡。 这使输入框成为 TUI 中唯一被填充的盒子(顶部 header 及其它边框区域仍透明)。若用户的终端背景与当前主题一致(预期搭配),填充是隐形且无缝的;若不一致,输入框现在会渲染成一个明显独立的彩色矩形。→ 如果"输入框应是实心主题背景"正是期望的视觉效果,则值得合并。
5. 📝 文档小瑕疵:描述称 theme.background.primary"已在 PermissionsDialog、StatsDialog、PrepareLabel 等组件中使用"。这些组件引用该 token 是作为强调背景上的前景文字色(反色文字),并非作为 Box 的 backgroundColor。本 PR 之后,BaseTextInput 是第一个、也是唯一一个把 theme.background.primary 当作 Box 背景使用的地方。
6. 📝 未新增测试;现有 3 个 BaseTextInput 测试只覆盖按键/粘贴。可用 ink-testing-library 写一个回归测试(断言换行行的帧在行尾单元格带有该背景 SGR)。

建议

可以合并 —— 正确、低风险、无回归、对所有主题优雅降级 —— 前提是项目希望输入框呈现为实心主题背景的盒子(见发现 #4)。非阻塞、可选:补一个小回归测试,并修正描述里"复用"的措辞。