Skip to content

截图标注态下,焦点位于文字输入框时单键应用内快捷键(T/M/B/1/2/3)仍被拦截,导致字母无法输入 #3770

Description

@simacai

联系方式

No response

发生了什么?

Environment

Snipaste 专业版 2.11.3(Windows 11,微软拼音输入法)

触发场景:截图 → 选文字工具 T → 在画面新建文本框 → 输入 b / m / t / 1 / 2 / 3

Steps to reproduce

启动截图,点击文字工具(或按 T)在截图上建一个文本框

切中文输入法,输入含 b/m/t 的拼音,或切英文直接敲 B M T

观察:B/M/T 不进文本框,而是被当作画笔/马赛克/文字工具切换键消费;主键盘 1/2/3 同理被吞,小键盘数字正常

首选项 → 控制 → 应用内快捷方式 里把 T/M/B 重绑成 Ctrl+Alt+T/M/B 后现象消失

Expected behavior

当标注画布内的焦点控件是文本输入控件(QTextEdit/QLineEdit 等),且输入法处于激活/合成状态,或纯英文焦点在文本框内时,应用内单键快捷键分发应短路返回,事件交给 Qt 控件/IME 处理,字母和数字正常落入文本。

Actual behavior

Snipaste 的标注界面 key event filter 在分发应用内快捷键前未判断 focusWidget() 是否为文本控件、也未判断 IME 合成状态,单键被提前消费,表现为字母/数字「被吞」。专业版虽支持重绑应用内快捷键(v2.11.3+ #2189/#3317/#3584),但属于绕行方案,不等于「输入框内触发单键快捷键」是合理默认行为。

Suggested fix

在应用内快捷键分发入口增加判断:

cpp
if (auto* w = focusWidget()) {
if (qobject_cast<QTextEdit*>(w) || qobject_cast<QLineEdit*>(w)) {
if (imeComposing() || true) return false; // 焦点在文本控件内,交还事件
}
}

同理 Ctrl+B/I/U 本就是文本框内字号格式键,不应与画布级快捷键混淆。

Reference

历史相关:#2078 远程桌面下 C 键被吞(2.8 宣称修复但部分场景仍在);社区 workaround do_not_omit_synthesized_c=true 仅覆盖合成 C 键,不解决通用单键问题。

运行平台

Windows 桌面

软件版本

2.11.3

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