Merge request sections append "/<section>" to the URL regardless of trailing slash

Summary

When opening a link to a merge request that ends in a slash, the tabs within the merge request form append their subsection URLs onto the end of the full URL, resulting in a double-slash in the URL. This is generally harmless, but when you view Changes in single-file mode, it breaks the previous/next buttons, causing them to send you to the main section of the merge request page instead.

Steps to reproduce

  1. Follow a link to any MR on any GitLab project that ends in a slash, or simply navigate to an MR and add a trailing slash to the URL.
  2. Click any of the tabs in the MR, and check the URL.

Example Project

No project necessary. Grabbing the top MR on the list right now, it can be seen from this link: !153330 (merged)

What is the current bug behavior?

When swapping to one of the MR tabs, the URL path segment for that section is appended after the slash, resulting in a double-slash in the URL.

What is the expected correct behavior?

The section's URL path segment is appended to the end of the MR URL properly whether or not the URL ends with a slash.

Relevant logs and/or screenshots

image

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)

Possible fixes