Global Search - Left Sidebar 2.0
Why WIP
-
Fix bug introduced by this original change: #281036 (closed) -
How to properly name this MR?
Important Information
This change was originally merged via: !46595 (merged)
This change introduced a bug: #281036 (closed)
This change was reverted: !47344 (merged)
The bug that was introduced incorrectly parsed query parameters with special characters. Specifically multi word searches that used +
GIF of Bug and Fix
| Bug | Fix | |
|---|---|---|
| Search with space/+ |  |
 |
Explanation of the regression
The original bug that caused the regression was the confusion in the frontend code between the + symbol and the %20 encode.
**In typical Unicode/UTF-8:**
| Name | Unicode |
|---|---|
space |
%20 |
+ |
%2B |
However, our implementation uses the + symbol as the way to indicate a space in the search query.
Now when a Query parameter reaches the frontend, we attempt to decode the query parameter. Since the + is used as a space and according to the decoder, this is already "decoded".
So it treats the + sign as a true plus sign.
Now the bug exposes self when we then attempt to update the search query as we encode the url back so that the request can properly read it. When we pass a plus sign to the encoder, it turns it into %2B which is the Unicode for a + sign as shown in the table. This of course was not the original search query.
Visualization:
Step 1. Query is extracted and decoded:
Query: ?search=Hello+World
UI Representation: Hello World
Decoded: Hello+World
Step 2. Query is encoded and sent to URL:
Query: ?search=Hello%2BWorld
UI Representation: Hello+World
Encoded: Hello%2BWorld
To fix this we simply run a quick replace in the URL before we decode it to properly replace any + symbols in the URL with a %20. So that way the decoder will properly decode it to a space character. There will be no collusion here as a true plus symbol will be represented as %2B a non-decoded URL.
What does this MR do (excluding the regression)?
Closes #241691 (closed)
This change creates a search facet sidebar for the issues and merge requests view. This will be the location we use in the future to add more search facets.
This change moves the Status and Confidential filter over to the facets and converts them to Radio Buttons from the Dropdown they were before.
These filters also do not auto apply, and instead they require an apply button to be pressed. This allowed us to remove a lot of logic from the filters themselves.
Screenshots (strongly suggested)
Desktop View
| Issues | Merge Requests | |
|---|---|---|
| Desktop View |  |
 |
Reset Filters
| No Filter | Filter | |
|---|---|---|
| Reset Filters |  |
 |
Smaller Views
| Medium (Tablet) | Mobile | |
|---|---|---|
| Smaller Views |  |
 |
Other Views (Unchanged)
| Before | After | |
|---|---|---|
| Projects |  |
 |
| Milestones |  |
 |
| Comments |  |
 |
| Code |  |
 |
| Commit |  |
 |
| Wiki |  |
 |
| Users |  |
 |
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
- [-] Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers - [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec - [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team
Related to #241691 (closed)