Two different keys record as the same shortcut when a layout puts punctuation on a letter key
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- desktop
Hướng nghiên cứu
Start in packages/shared/src/keybindingMatching.ts, where shortcutKeyFromEvent chooses between event.key and event.code via EVENT_CODE_SHORTCUT_KEYS, and where recordedLayoutShortcutKey and resolveEventKeys decide what gets stored and matched. Reproduce the collision by checking that a keydown with key '.' and code KeyH is recorded differently from key '.' and code Period. Done means those two keys no longer record the same shortcut, while letter-layout cases such as Colemak and AZERTY (#7995) still behave as before. The mapping rule needs a maintainer decision first.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happened
On Linux (Hyprland, Wayland) with a custom XKB layout that puts . on the physical H key, Ctrl+H and Ctrl+. both record as ctrl+. in Settings → Keybindings. The two can't be bound separately. A ctrl+. binding fires on both keys, and on H a ctrl+h binding fires as well.
Diagnosis
Chromium reports:
- physical Ctrl+H:
key=".",code=KeyH - physical Ctrl+.:
key=".",code=Period
In packages/shared/src/keybindingMatching.ts, shortcutKeyFromEvent keeps event.key only when it is a letter. Otherwise it maps punctuation event.codes through EVENT_CODE_SHORTCUT_KEYS and falls back to event.key:
- KeyH:
.isn't a letter and KeyH isn't a punctuation code, so it falls back to"." - Period: maps to
"."
recordedLayoutShortcutKey records "." for both. resolveEventKeys returns {".", "h"} for KeyH and {"."} for Period, so ctrl+. matches both keys.
The ambiguity comes from mixing two rules: the layout symbol for letters, and the physical key for punctuation. When event.key is punctuation but event.code is Key[A-Z], one option is to record and match by that letter, as resolveEventKeys already adds it for matching. That keeps Colemak and AZERTY (#7995) working.
Steps to reproduce
- On Linux, use an XKB layout whose base symbol on the physical H key is
., e.g.key <AC06> { [ period, parenright ] };while<AB09>keeps.reachable. - Settings → Keybindings: record a shortcut with Ctrl + physical H. It records
ctrl+.. - Record another with Ctrl + physical
.. It also recordsctrl+., so the two conflict.
Version
0.1.10-nightly.20261111.4544 (desktop AppImage, commit 1264c206). No changes to the shortcut matching or recording code through main as of 2026-11-13 (nightly 0.1.10-nightly.20261113.4616).
Environment
NixOS, Linux 6.18 x64, Hyprland (Wayland), custom XKB layout (Halmak-based, with a Ctrl/Super level that gives QWERTY symbols), keyd 2.6.0.
Evidence
`keydown` events captured inside T3 Code Desktop, with no key remapping active for the app:
mods=ctrl key="." code=KeyH keyCode=72
mods=ctrl key="." code=Period keyCode=75
mods=ctrl key="e" code=KeyK keyCode=69
mods=ctrl key="v" code=KeyC keyCode=86
mods=ctrl key="c" code=KeyV keyCode=67
Chromium ignores the layout's Ctrl level for most keys. That part is upstream Chromium behaviour and isn't what this issue asks to fix. The collision between the first two lines happens in T3's own logic.
Related issues
#7995 / PR #4469 (shortcuts now follow layout symbols), #15954 / open PR #24034 (layout map for macOS Option shortcuts; same files, doesn't cover this case), #14833 (German +).
Fix applied or workaround
None.
Filed by
Claude Opus 5.5 (claude-opus-5-5) through T3 Code triage, in Claude Code.
- Ngôn ngữ chính
- TypeScript
- Star
- 24.8k
- Fork
- 6.4k
- Merge trung bình
- 59 phút
- Pull request đã merge (30 ngày)
- 418
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pingdotgg/t3code
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
via-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: MCP App inline frames never go below 80px, so compact apps get blank space under themĐang mở
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Question card options show LaTeX as raw source, though the question text renders itCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Settings inheritance popover shows raw slugs for branch naming, default permissions and response streamingCó thể đã có người làm @juliusmarminge đã nhận 1 ngày trước. Đang mởvouch:denounced
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pingdotgg/t3code
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
nikoheikkila/nikoheikkila.fi#1131 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Resources: Update work of urumqiCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
railmapgen/rmp-gallery#4176 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
GraphQL custom headers duplicate differently cased default headersCó thể đã có người làm @yxr-2025 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
elie222/rakazo#4625 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[New Project]: PacaĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
github/forgoodfirstissue#574 ·