With 'Show one file at a time' selected, resetting the MR Changes version control, dropdown resets to the first file in the list
Summary
This is a source of frustration for our viewers trying to view the history for a specific file in an MR that touches multiple files.
Users have 'Show one file at a time' selected. In the 'Changes' tab, as the user is navigating through the File browser, if the user wants to view the history of changes for a file, then updating the MR version control dropdowns (e.g., base, latest version) will reload the page and switch to the first file in the browser as opposed to retaining the current file context.
This causes a cognitive burden for reviewers to remember what file they were reviewing, and to then click into that every time.
This makes for a very frustrating experience.
It seems pretty clear from a user's request in 'Show one file at a time' mode that the file context must be preserved when the versions are updated.
This can be fixed by keeping the file context and showing the new version diff for the previously selected file, instead of resetting the user-selected file.
Steps to reproduce
Example Project
What is the current bug behavior?
What is the expected correct behavior?
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)