Double encoding occurs when filtering tags containing spaces in the Issues listing
Summary
When navigating to the issues page for a project, filtering by tags with spaces can cause previously escaped HTML characters to become double-escaped, thus returning no results on re-filtering a set of issues.
Steps to reproduce
- Go to the issues page for a project hosted on GitLab CE version 8.11.4, or the cloud version at www.gitlab.com
- Create a multiple word tag (with spaces separating words) if one does not already exist.
- With either a new or existing Issue, attach the tag from step 2 to this issue.
- From the main Issues page, filter by the tag created in step 2. You should see the issue from step 3 in the listing.
- Click the label option to change the filtering, and leave the set of selected labels alone. Click either outside the window, or the x to have your browser issue a new request for another set of filtered issues.
The tag name becomes double encoded, and %20
in your tag becomes %2520
(Recall that %
is escaped as %25
)
Expected behavior
A tag should not become double-encoded when narrowing down a set of issues by performing a second filtering of issues.
Actual behavior
HTML escaped characters enter when a tag has a space in it which renders the filter ineffective, as nothing will match the new tag name.
Screenshots
Tag is indeed not checked if you look at the tag list
Output of checks
This occurs on the current version of the hosted gitlab.com instance and so I cannot generate the output of health checks.
Possible fixes
My gut tells me that GitLab is pushing the encoded version back into the UI for the tags, which causes it to be escaped a second time when you perform a second filter request on the results of the previous filter request.