<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=572220) </details> <!--IssueSummary end--> <!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> The ["Move to next commit"](https://docs.gitlab.com/18.4/user/shortcuts/#:~:text=Move%20to%20next%20commit.) shortcut <kbd>c</kbd> is very useful in the MR diff view. But currently, it conflicts with the ["Copy merge request reference"](https://docs.gitlab.com/18.4/user/shortcuts/#:~:text=Copy%20merge%20request%20reference.) shortcut <kbd>c</kbd>+<kbd>r</kbd>. This results in the next commit shortcut not working most of the time. It works only when holding <kbd>c</kbd> down or pressing <kbd>c</kbd> twice in quick succession. The Mousetrap library [docs also say](https://craig.is/killing/mice#:~:text=It%20is%20important%20to%20note%20that%20Mousetrap%20can%20get%20very%20confused%20if%20you%20have%20a%20single%20key%20handler%20that%20uses%20the%20same%20key%20that%20a%20sequence%20starts%20with.%20This%20is%20because%20it%20can%27t%20tell%20if%20you%20are%20starting%20the%20sequence%20or%20if%20you%20are%20pressing%20that%20key%20on%20its%20own.) conflicts like this can occur: > It is important to note that Mousetrap can get very confused if you have a single key handler that uses the same key that a sequence starts with. This is because it can't tell if you are starting the sequence or if you are pressing that key on its own. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> 1. Navigate to a MR with multiple commits 2. Go to the "Commits" tab and click on the latest commit (topmost in the list) 3. Press the <kbd>x</kbd> key once. Observe how the previous commit navigation works fine. 4. Press the <kbd>c</kbd> key once. Observe how nothing happens. 5. Press <kbd>c</kbd> multiple times, with varying speed. Observe how it sometimes works properly. ### Example As an example, I picked some random MR. You can try out the shortcuts here: - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/205020/diffs?commit_id=aee9aeeba3831143fa041ebbc45a8d827e68ef4d ### What is the current *bug* behavior? <!-- Describe what actually happens. --> The "Next commit" navigation shortcut <kbd>c</kbd> does not work as intended, only working intermittently, on double presses, or when holding the key down. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> The "Next commit" navigation shortcut <kbd>c</kbd> works immediately, when pressing they key once and every time (unless you're already at the last commit). ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> This bug happens on GitLab.com <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> #### Option 1 – Less effort, higher outside impact **Change out one of the keybinds.** Preferably the "Copy reference" keybind should be changed out; since the commit navigation keybinds are next to each other on the keyboard, it would be odd to move one of them. Next to <kbd>x</kbd><kbd>c</kbd> is also <kbd>v</kbd>, which marks a file as viewed in the diff view. The relevant keybinds are defined here: - [`MR_COMMITS_NEXT_COMMIT`](https://gitlab.com/gitlab-org/gitlab/-/blob/fbef2f56000bfaff78e159b2f8bcf738a5c9b368/app/assets/javascripts/behaviors/shortcuts/keybindings.js#L559): `'c'` - [`ISSUABLE_COPY_REF`](https://gitlab.com/gitlab-org/gitlab/-/blob/fbef2f56000bfaff78e159b2f8bcf738a5c9b368/app/assets/javascripts/behaviors/shortcuts/keybindings.js#L454): `'c r'` There would also be a documentation change, since currently the keybinds help view (opened with <kbd>?</kbd>) shows the "Copy reference" shortcut as being unified for work items and MRs. #### Option 2 – More effort, lower outside impact **Disable the "Copy reference" keybind in the MR commit-based diff view** This would be preferred to option 1. Since no shortcuts are changed, user's won't need to un-learn any muscle memory they might already have. The keybind is activated in [`shortcuts_issuable.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/03fbc1d6673fa7d417bda036b03829b0181fb751/app/assets/javascripts/behaviors/shortcuts/shortcuts_issuable.js).