Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#867 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c
Domain
desktop, operating-systems

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C
Stars
247
Forks
126
Avg merge
10d 6h
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from linuxmint/muffin

All issues in linuxmint/muffin

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.