Skip to content

【Bug】PreviewConfirm 模式下润色文本重复插入(嵌套重叠) #1014

Description

@tonyzaca7755963

问题描述

在使用 PreviewConfirm 输出模式(先预览润色结果、用户确认后再插入)时,最终插入目标应用的文本会出现重复:原始润色内容出现一次,且同样的内容还会嵌套在第一段文字的末尾几个字中间,形成"结尾重叠"的效果。

复现步骤

  1. 在设置中将"选区润色输出模式"设为 PreviewConfirm(预览确认)
  2. 在任意 Windows 应用(尤其是 Electron / Chromium 内核、QT、富文本编辑器)中选中一段文字
  3. 触发选区润色快捷键,等待润色完成后在预览窗口点击"确认替换"
  4. 观察目标应用中插入的文本

实际现象

插入文本出现两遍,第二遍嵌套在第一遍末尾数个字中间,例如:

润色后的完整内容润色后的完整内容整内容

(示意:前半段完整,后半段从某处开始重复)

期望现象

目标应用中只出现一遍润色后的文本,完整替换原来的选中内容。

根本原因分析

confirm_selection_polish_preview 在执行 Ctrl+V 粘贴之前,会调用 validate_selection_insertion_target。该函数在 Windows 上会向目标应用发送一次真实的 Ctrl+C 按键,以重新读取当前选区文本进行校验。

这次 Ctrl+C 会破坏许多 Windows 应用的活动选区状态,导致随后的 Ctrl+V 无法正确替换选中文本,而是在光标所在位置插入,从而产生嵌套重复的效果。

修复方案

在 PreviewConfirm 路径中,改用仅校验窗口身份(HWND)的验证函数,跳过 Ctrl+C 重读步骤。

理由:

  • 用户已在预览窗口明确确认了替换操作,无需再次读取选区内容
  • reactivate_selection_insertion_target 已经恢复了目标窗口的焦点和活动选区
  • HWND 校验足以检测用户在预览期间是否切换了应用窗口

DirectReplace 路径(无预览直接替换)仍保留完整的 Ctrl+C 校验逻辑,因为 LLM 调用期间用户有可能已经移动或改变了选区。

环境

  • 操作系统:Windows
  • 受影响模式:SelectionPolishOutputMode::PreviewConfirm

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions