add_custom_keybinding() returns a valid action id for an unparseable accelerator: no grab, no warning, dead shortcut

Đã đóng
#867 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

@DerLinke đang làm issue này rồi.

Từ ngày 14/10/2026.

  • #872 của @DerLinke — đang mở

Đá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):

  1. src/core/keybindings.c:1068 meta_display_add_custom_keybinding() → add_keybinding_internal() (line 967)
  2. add_keybinding_internal() returns the result of meta_prefs_add_keybinding() (src/core/prefs.c:2212)
  3. meta_prefs_add_keybinding() parses the strings through update_binding (pref, strokes); and then returns TRUE unconditionally:
  update_binding (pref, strokes);
  g_strfreev (strokes);

  g_hash_table_insert (key_bindings, g_strdup (name), pref);

  return TRUE;
}
  1. 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
  1. gsettings set org.cinnamon.desktop.keybindings.custom-keybinding:/org/cinnamon/desktop/keybindings/custom-keybindings/custom0/ binding "['<Print>']"
  2. gsettings set org.cinnamon.desktop.keybindings.custom-keybinding:/org/cinnamon/desktop/keybindings/custom-keybindings/custom0/ command "flameshot gui"
  3. gsettings set org.cinnamon.desktop.keybindings custom-list "['custom0']", then reload Cinnamon's bindings (or log out/in)
  4. pressing Print does nothing; no grab is installed for that key (xinput test-xi2 --root shows the RawKeyPress/KeyPress but no FocusIn (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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của linuxmint/muffin

Tất cả issue của linuxmint/muffin

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.