Can't scroll to merge request code comment if comment is outside of changed scope
Summary
This is probably related to, but not covered by, issue #207074 (closed).
In that issue, the reporter puts a review comment on a "white" line; that is, one outside of the changed scope. The reporter claims that submitting the review then fails --- for me this works. But! When viewing the merge request, and clicking Jump to first unresolved thread, it goes to the correct web page, but does not display the comment because that part of the code is collapsed. Expanding the file sufficiently with either Show all unchanged lines or Show 20 lines causes the "Jump to" functionality to work, so it's really just a matter of not being clever enough to ensure all commented code is expanded.
Steps to reproduce
- (User A) Create a merge request of some file such that the change is after a sufficiently large amount of code to cause it to be collapsed.
- (User B) Review the merge request, expand the top section, and enter a comment for any erstwhile hidden line.
- (User B) Submit the review. This is expected to work.
- (User A) Review the review, and click the "Jump to first unresolved thread".
- (User A) If you didn't know there was a hidden comment, you would be very confused why GitLab is showing you a part of the file that does not display a comment...
Example Project
You probably can't access this, but this is a direct link to where such an error occurs. Using this link, the code block will be expanded and the "Jump to" functionality will work as intended. Loading the page with only "http:// [...] merge_requests/33/" will show the faulty behaviour.
Clicking the "Jump to first unresolved thread" takes you to the "Changes" tab, but shows a part of a file that does not appear to have a comment (or worse, it has a different comment near enough that you make the wrong assumption).
What is the expected correct behavior?
Clicking the "Jump to first unresolved thread" takes you to the "Changes" tab, and shows a part of a file that has a comment (possibly after having expanded the surrounding block).
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
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)