Dangerous "Viewed" state prefetch behavior in MR Changes single file view

Summary

In the Changes Tab of a Merge request, when using "Show one file at a time", the modification state of other files is not correctly prefetched.

If a file is previously marked as "Viewed", but was since modified in a new commit, it will not be highlighted as modified until it or its direct neighbors are selected.

This is dangerous, as a reviewer I rely on the highlighting to figure out which files I have to check again. This might lead to unchecked changes being approved and merged.

Steps to reproduce

  • Create a MR with multiple (>10) files
  • In the changes tab select "Show one file at a time"
  • Mark most of the files as "Viewed"
  • Push a new commit, that modifies most viewed files
  • Reload the Changes tab, it should now compare the main to the new "latest version"
  • The modified files will only change to the bold highlighting and lose the "viewed" flag, when they (or their neighbors) are selected

Example Project

Should happen in any project. We are on GitLab Enterprise Edition v18.6.1-ee

What is the current bug behavior?

After a reload of the MR Changes tab, changed files are not highlighted.

Some updates ago the issue was reversed, where all files were displayed as unviewed until fetched, which was also annoying, but less dangerous.

What is the expected correct behavior?

Changed files should immediately be highlighted in bold.

Relevant logs and/or screenshots

N/A

Output of checks

Results of GitLab environment info

GitLab Enterprise Edition v18.6.1-ee

Results of GitLab application Check

please ask our company representative

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖