<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve The recently shipped feature of reviewing File by file in MRs https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35223 is buried in the User preferences (https://gitlab.com/profile/preferences). Users should be able to toggle it on and off from the MR page itself. ### Intended users All users of MRs. ### User experience goal Easily toggle on and off the preference. ### Proposal <img src="/uploads/9dca3bd6d53e10035f752a5945a98f83/Screenshot_2020-08-06_at_11.12.16.png" width="500"> ### Further details While we have the feature flag, this needs to be tied to the same feature flag. Another detail: * What should we do with the User preference in the settings? Keep these two places always in sync? Or remove it from the user settings? ### Documentation An update to this section is in order: https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references See Epic for related work: https://gitlab.com/groups/gitlab-org/-/epics/516 <!-- Label reminders - you should have one of each of the following labels if you can find the correct ones! Type - for example ~feature ~bug ~documentation ~meta /label ~"feature::addition" ~"feature::maintenance" ~tooling ~"tooling::pipelines" ~"tooling::workflow" per https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#type-labels DevOps stage - for example ~"devops::secure" Group - for example ~"group::composition analysis" Category - for example ~"Category:Dependency Scanning" <!-- Label reminders - you should have one of each of the following labels if you can figure out the correct ones! --> ### Release Notes Using [single-file diff mode](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation) is useful to improve performance and navigation of large merge requests, however, enabling it previously meant leaving the merge request, going into user preferences, and enabling the option. This releases introduces the capability to enable single-diff mode right within the merge request view. As you navigate to the "changes" tab of the merge request, simply click the gear icon and check the box labeled `Display one file at a time`. This will display a single file at a time and enable the `prev` and `next` buttons to navigate among files.