add_custom_keybinding() returns a valid action id for an unparseable accelerator: no grab, no warning, dead shortcut
Đá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
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- c
- Lĩnh vực
- desktop, operating-systems
Hướng nghiên cứu
Start in src/core/prefs.c at meta_prefs_add_keybinding() and update_binding(), then trace the return through src/core/keybindings.c at meta_display_add_custom_keybinding(). Reproduce with the gsettings accelerator examples or the Cinnamon DBus check. Done means an unparseable binding is reported as unsuccessful or its warning is visible, rather than being stored as an active dead shortcut.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Distribution
Linux Mint 22.3 Cinnamon (Zena), 64-bit, X11 session
Package version
muffin 6.6.3+zena (cinnamon 6.6.9+zena, GLib 2.80.0, gjs)
Graphics hardware in use
ASUSTeK ROG Flow Z13 (AMD Radeon, chip-ID 1002:1586, amdgpu), kernel 7.0.0-34-generic, X11
Frequency
Always
Bug description
meta_display_add_custom_keybinding() accepts an accelerator string that cannot be parsed, returns a valid (non-META_KEYBINDING_ACTION_NONE) action id for it, installs no grab, and — as far as I can tell — never emits the warning it intends to emit. The caller therefore believes the shortcut was registered, and the key silently does nothing.
Reproduced with a custom shortcut bound to <Print> (a keysym wrapped in angle brackets with no modifier — gtk_accelerator_parse("<Print>") returns keyval 0; GTK wants <Shift>Print, and a lone key as Print):
| accelerator | gtk_accelerator_parse() |
key press result | addHotKeyArray() return |
|---|---|---|---|
Print |
ok (keyval 0xff61) | fires | true |
<Shift>Print |
ok | fires | true |
<Print> |
keyval 0 (parse failure) | nothing | true |
<NotAKeyAtAll> |
keyval 0 | nothing | true |
PrintScreen |
keyval 0 | nothing | true |
The code path (muffin 6.6.3):
src/core/keybindings.c:1068meta_display_add_custom_keybinding()→add_keybinding_internal()(line 967)add_keybinding_internal()returns the result ofmeta_prefs_add_keybinding()(src/core/prefs.c:2212)meta_prefs_add_keybinding()parses the strings throughupdate_binding (pref, strokes);and then returnsTRUEunconditionally:
update_binding (pref, strokes);
g_strfreev (strokes);
g_hash_table_insert (key_bindings, g_strdup (name), pref);
return TRUE;
}
update_binding()itself does detect the failure and intends to report it:
if (!meta_parse_accelerator (strokes[i], combo))
{
meta_topic (META_DEBUG_KEYBINDINGS,
"Failed to parse new GSettings value\n");
meta_warning ("\"%s\" found in configuration database is not a valid value for keybinding \"%s\"\n",
strokes[i], binding->name);
g_free (combo);
/* Value is kept and will thus be removed next time we save the key.
* Changing the key in response to a modification could lead to cyclic calls. */
continue;
}
so the MetaKeyPref ends up with combos == NULL (nothing to grab) while its caller still reports success.
This contradicts the documented contract of the API in the same file:
* Returns: the corresponding keybinding action if the keybinding was
* added successfully, otherwise %META_KEYBINDING_ACTION_NONE
Consequence in Cinnamon (js/ui/keybindings.js, addHotKeyArray, line 256): because the returned action id is not Meta.KeyBindingAction.NONE, Cinnamon stores the binding in this.bindings and returns true, and its own diagnostic (line 285: global.logError("Warning, unable to bind hotkey with name '" + name + "'. The selected keybinding could already be in use.")) is never reached. The user gets a shortcut that is listed as active and does nothing.
Additionally, I could not find the meta_warning() above anywhere on this system for that case: ~/.xsession-errors has zero occurrences of not a valid value for keybinding, there is no ~/.cinnamon/glass.log and no /var/log/muffin*, and journalctl --user -b contains no such line. So the one diagnostic that would have explained the dead shortcut is invisible (or never emitted on the dynamic/custom-keybinding path).
Steps to reproduce
gsettings set org.cinnamon.desktop.keybindings.custom-keybinding:/org/cinnamon/desktop/keybindings/custom-keybindings/custom0/ binding "['<Print>']"gsettings set org.cinnamon.desktop.keybindings.custom-keybinding:/org/cinnamon/desktop/keybindings/custom-keybindings/custom0/ command "flameshot gui"gsettings set org.cinnamon.desktop.keybindings custom-list "['custom0']", then reload Cinnamon's bindings (or log out/in)- pressing Print does nothing; no grab is installed for that key (
xinput test-xi2 --rootshows theRawKeyPress/KeyPressbut noFocusIn (NotifyGrab)/FocusOut (NotifyUngrab), while a working binding such as the volume key shows them); nothing is logged.
Equivalent live check through Cinnamon's DBus Eval: Main.keybindingManager.addHotKeyArray('diagx',['<Print>'],()=>{}) returns true.
Expected behavior
A binding whose accelerator cannot be parsed should either be rejected — meta_prefs_add_keybinding()/add_keybinding_internal() should fail so the caller can report it, consistent with the documented META_KEYBINDING_ACTION_NONE return — or at minimum the failure should be visible in the log, not silent. As it stands, one bad string in a shortcut's binding array produces a dead shortcut with no trace anywhere.
Suggested fix (sketch)
In meta_prefs_add_keybinding() (src/core/prefs.c), make update_binding() report whether every stroke parsed, and return FALSE (or propagate a "no combos" condition) when nothing could be parsed, so meta_display_add_custom_keybinding() can return META_KEYBINDING_ACTION_NONE. Also ensure the meta_warning() in update_binding() actually reaches the log for the dynamic path.
- Ngôn ngữ chính
- C
- Star
- 249
- Fork
- 131
- Merge trung bình
- 11 ngày 23 giờ
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
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 linuxmint/muffin
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
-
llvmpipe is reported as hardware accelerated since 5.4, so software rendering is never detectedĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Tất cả issue của linuxmint/muffin
Issue tương tự
-
documentation severity: low
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
luainkernel/lunatik#2231 ·
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 72/100
apache/arrow-swift#209 ·
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 78/100
libretiny-eu/libretiny#435 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Needs-Triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
trezor/trezor-firmware#8210 ·
Maintainer thường phản hồi trong vòng 3 ngày