排队发送后，为什么不能编辑带图片的排队消息

[0Sakura721]

如上

[takomitkm]

这是当前默认实现的有意限制，不是故障。

带图片的排队消息在队列里属于「混合内容（文字 + 附件）」条目。队列行的行内编辑器只处理纯文本，所以对非纯文本条目直接禁用了「编辑」（Edit）；官方测试也明确断言了这一限制。纯文本的排队条目是可以在原地编辑的，保存时沿用原队列 item ID。

源码/测试依据（固定在 fcc0ad4）：

• 混合内容守卫 QueueDock.tsx#L24–L26：

  deepseek-harness/packages/client/ui-conversation/src/client/queue/QueueDock.tsx

  Lines 24 to 26 in fcc0ad4

  	function textOf(content: InboxState['next-turn'][number]['content']): string | null {
  	if (!content.every(block => block.type === 'text')) return null
  	return content.map(block => block.text).join('')

• 官方测试「混合条目禁编辑」queue-dock.client.spec.tsx#L506–L525：

  deepseek-harness/packages/client/ui-conversation/tests/queue-dock.client.spec.tsx

  Lines 506 to 525 in fcc0ad4

  	it('renders active actions and disables editing for mixed-content rows', () => {
  	const snap = snapshotWith([
  	row('i-1', '第一条排队消息'),
  	row('i-2', null, 'image [image]'),
  	])
  	const source = liveSession(snap)
  	const { container, getByRole } = render(
  	<QueueDock {...kitFor(snap)} useSession={source.useSession} useProjection={source.useProjection} />,
  	)
  	fireEvent.click(getByRole('button', { name: '2 条排队消息' }))
  	expect([...container.querySelectorAll('li')].map(item => item.textContent))
  	.toEqual(['第一条排队消息', 'image'])
  	expect(container.querySelectorAll('button')).toHaveLength(7)
  	expect(container.querySelectorAll('[aria-label="编辑排队消息"]')).toHaveLength(2)
  	expect(container.querySelectorAll('[aria-label="删除排队消息"]')).toHaveLength(2)
  	expect(container.querySelectorAll('[aria-label="插话发送"]')).toHaveLength(2)
  	expect((container.querySelectorAll('[aria-label="编辑排队消息"]')[0] as HTMLButtonElement).disabled).toBe(false)
  	expect((container.querySelectorAll('[aria-label="编辑排队消息"]')[1] as HTMLButtonElement).disabled).toBe(true)
  	expect(container.querySelectorAll('[aria-label="编辑排队消息"]')[1]?.getAttribute('title'))
  	.toBe('包含非文本内容，暂不支持编辑')

• 纯文本原地编辑保留 item identity（同文件 #L602–L624）

原因：原地改字要同时保住原 content block 的顺序、附件的 durable ID 和非文本块，而当前行内编辑的 schema/handler 只覆盖纯文本；直接放开会让附件结构错位，所以先禁用了。

现在能做的：把这条排队项删除后在输入框重新编辑（图片需重新添加）；或用 steer 追加指令；缩略图、删除、steer 对混合条目仍然可用。（默认 QueueDock 目前没有「把整条排队消息取回主草稿再改」的入口，那是另一个需求方向。）

这里说的「排队后改字」，其实更适合作为 Ideas 提一条需求——举个现成例子：我自己就在同一块区域提过一条 #12519（关于提交等待 Host 接纳期间如何交接输入框，正文里也连带讨论了 #3501「带图片消息挂起后输入框只读」），你可以参考它的写法，单独提一条针对「带图片的排队消息原地改字」的需求。

以上按 master fcc0ad4 核对，你的版本若不同可能细节略有出入。

[codersongs]

感谢解释。想确认两点后续方向：

1. 这个限制是因为行内编辑框目前只支持纯文本（属于实现现状，后续可能补附件编辑），还是产品上暂时不打算支持编辑带附件的排队消息？
2. 如果后续支持替换/删除附件，会沿用原 queue item id（队列位置/顺序不变）和原 rpcId（与发送回执、乐观气泡的关联不变）吗？还是会走「删除旧项 + 重新入队」的路径？

补充：桌面端 0.2.2-rc.1（macOS）也是同样表现——带图片的排队消息只能删除、不能编辑；纯文本行可以原地编辑。和 web 一致。

[takomitkm]

同问，依旧等官方等得好苦

[sljdxde]

补一条这条帖没覆盖到的点：「为什么不能编辑」的解释本身，用户永远看不到。

上面 takomitkm 的结论我复核后同意——混合内容禁用编辑是有意限制，不是故障。但沿着同一条代码往下读，会发现解释被放在了一个到不了的地方，而且代码注释里给出的理由经实测不成立。

现状

master 39163dd 上，QueueDock.tsx 的编辑按钮：

• L267 —— Tooltip ... disabled={text === null}：恰好在需要解释的那一刻，组件自己的 Tooltip 被关掉。
• L272-L275 —— 注释写「Disabled buttons fire no hover events, so the unsupported hint stays a native title」，于是只剩原生 title。

文案本身在 locales.ts L388 八种语言都写好了，实际等于死代码。

注释里的前提，实测不成立

「Disabled buttons fire no hover events」这条判断，在当前的 Chrome 上不成立。我在 macOS + Chrome 157 实测：

观测	结果
pointerover / pointerenter / mouseover / mouseenter 在 disabled 按钮上	全部正常触发
React 的 onPointerEnter 挂在 disabled 按钮上	正常触发（在 cloneElement 注入的锚点上复现）
Tooltip 挂在 disabled 按钮上、且 disabled={false}	气泡正常显示

也就是说：按钮禁用并不阻断悬停事件，Tooltip 本身完全能在禁用按钮上工作。唯一让它不出现的，就是 disabled={text === null} 这个 prop 自己。

这也解释了为什么这个缺陷能长期存在——写出注释的人相信了一个常见但过时的说法（在 pointer-events: none 或更老的浏览器上确实成立），于是选择了原生 title 这条更差的通道，而 title 的视觉呈现本身又不跨平台一致（无障碍树里能读到，但各浏览器/平台是否画出气泡并不统一，且约 1 秒延迟、无样式）。

现有测试为什么没拦住

queue-dock.client.spec.tsx#L506-L525 的断言是：

expect(buttons[1]?.getAttribute('title')).toBe('包含非文本内容，暂不支持编辑')

只断言属性存在，不断言用户能到达它。所以这个 UX 缺陷可以带着全绿测试长期存在。

用户侧表现

带图片的排队消息上，编辑图标变灰、点击无反应、悬停无任何解释——用户无法区分「这条不能编辑」「按钮坏了」「还在发送中」三种状态。我在 0.2.2-rc.2 的 web 端复现，与 #12594 描述一致。

建议的修复

修复不需要包一层 span——实测证明 Tooltip 挂在禁用按钮上本来就能工作，只要别自己把它关掉：

<Tooltip
  portal
  label={text === null ? t('queue.edit.unsupported') : t('queue.edit')}
  side="bottom"
  delayMs={500}
>
  <button
    type="button"
    className={css.action}
    aria-label={t('queue.edit')}
    disabled={busy !== null || text === null}
    onClick={() => { if (text !== null) setEditing({ id: row.id, text }) }}
  >

即：去掉 disabled={text === null}，让 label 随状态取值，并去掉按钮上的 title（否则会和样式化气泡重复显示）。按钮仍是 disabled，编辑语义不变，只是让禁用态能解释原因。

配套把 spec 的断言从「有 title 属性」改成「悬停可见解释文案」，否则同样的回归还会再出现。

与相邻需求的关系

真正的能力缺口（只改文字、保留附件）已经在 #11236 的评论里提过方案，我不在这里重复。本条只针对可发现性：即使短期不支持编辑，也应该让用户知道为什么。

补充一句边界：我只在 macOS Chrome 上做了上述实测，没有验证 Safari 和 Firefox。如果确实存在「某些浏览器不给禁用控件派发鼠标事件」的情况，那 span 包裹方案可以作为兜底；但在 Chrome 上它不是必需的，而 Chrome 是当前 web 端的主要场景。

[takomitkm]

1. 关于“死代码”：queue.edit.unsupported 不是死代码，更像“预留 i18n”

这点是我和你唯一有分歧的地方。L274 确实把该字符串写进了 DOM title；8 种语言都有（中文“包含非文本内容，暂不支持编辑”）；spec L522–525 也断言了该 title。也就是说它不是没接上，只是唯一出口是原生 title——Mantine 那个 styled 气泡在 L267 因 text === null 被 disabled 关掉了。所以与其叫“死代码”，不如说是“预留 i18n”（8 语言全量翻译、经原生 title 兜底），并不是真的死。

2. 关于 disabled 按钮的 hover：和你一致，只补一处边界

这点不展开——我在校机上也验了（Windows 11 + Edge 157 / Chromium 157 一代），结论和你一样：hover / pointer 一族照常触发。唯一补一句边界：被吞的是 mousedown / click / focus，触发的是 hover 而非激活，所以 L272–273 注释的前提不成立，但按钮的点击语义并没有失效。

顺着看：既然 disabled 实际会触发 hover，那“因为收不到 hover 才退回原生 title”的理由就不成立，可直接去掉 L267 的 disabled={text === null}，用 styled tooltip 出提示，省掉 title 这条并行通道。