Fix: Keyboard shortcuts cannot be edited in Preferences (closes #14237)#14312
Conversation
Hey @AmandaBalderas20!Thank you for contributing to JabRef! Your help is truly appreciated ❤️. We have automatic checks in place, based on which you will soon get automated feedback if any of them are failing. We also use TragBot with custom rules that scans your changes and provides some preliminary comments, before a maintainer takes a look. TragBot is still learning, and may not always be accurate. In the "Files changed" tab, you can go through its comments and just click on "Resolve conversation" if you are sure that it is incorrect, or comment on the conversation if you are doubtful. Please re-check our contribution guide in case of any other doubts related to our contribution workflow. |
|
Thanks a lot for your PR, please check the failing tests in KeyBindingsTabModelTest. Maybe they need to be adapted? |
|
|
||
| Optional<String> saved = prefsRepo.get(binding); | ||
| assertTrue(saved.isPresent()); | ||
| assertTrue("ctrl+shift+L".equalsIgnoreCase(saved.get())); |
There was a problem hiding this comment.
Can you make this an assertEquals? This makes it easer to see the diff when tests fails
There was a problem hiding this comment.
You can just do assertEquals(Optional.of("...."), saved)
|
Tess work for me on mac as well. |
No - you fixed an issue. Please add a line - you can ref the issue there #14237 |
|
KeyBindingsTabModelTest fails. I cannot verfiy it because there is an assumeFalse(OSX) inside, so the tests do not run on mac |
|
Locally Not sure how to proceed
|
|
I reviewed it and I think the failing tests in KeyBindingsTabModelTest expect hasChanged to be false after resetting a key binding. |
|
It would be great if you add this as comment to the test somehow |
|
Okay, so I’ll update the tests and add a comment explaining why hasChanged() is now expected to be true after a reset (because of the fix for #14237) |
Head branch was pushed to by a user without write access
| assertTrue(saved.isPresent()); | ||
| assertTrue("ctrl+shift+L".equalsIgnoreCase(saved.get())); | ||
| assertEquals(Optional.of("ctrl+shift+L"), saved); |
|
Does not seem to fix the issue on JabRef 6.0-alpha.194--2025-11-24--5e08c82 New keycombinations are ignored. How are they supposed to be entered? |
|
@Scroogeee |
|
I did try doing it on JabRef 6.0-PullRequest14057.266--2025-11-28--a581582 the broom clears the combination, but the new key combination is ignored |
|
@Scroogeee Sorry for the late reply. For me it worked. Just maybe a thing, if you want to have a shortcut using command key, you need to press ctrl key instead. It will be automatically mapped to command under the hood |
Should we add this as hint at the dialog somehow? It is strange that keys are remapped somehow? I assume, this is only the case at JabRef - or is this a general issue happening in all apps? |
|
Yeah somehow at the dialog this would be helpful. jabref/jabgui/src/main/java/org/jabref/gui/keyboard/KeyBindingRepository.java Lines 154 to 163 in 518f61f But it seems like javafx supports shortcut key for such cases
https://openjfx.io/javadoc/24/javafx.graphics/javafx/scene/input/KeyCombination.html |
|
Key remapping is no longer need thanks to javafx shortcuts, folllow up in #14684 |

Closes #14237
I fixed an issue where keyboard shortcuts could not be edited in:
Preferences → Keyboard shortcuts.
The KeyEvent was being consumed by global application shortcuts before reaching
the shortcut editor in the KeyBindingsTab. As a result, pressing keys did not
update the selected shortcut, and changes were not persisted.
This PR adds:
Steps to test
Screenshots visible changes are not required since UI remains the same.
Mandatory checks
CHANGELOG.md