UX: Filters in Issues/MRs don’t update until “Search” is clicked, feels unresponsive
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary When modifying or removing filters in the Issues or Merge Requests search bar, results (and query params) are not updated until the Search button is pressed. This makes the search feel unresponsive and inconsistent with user expectations.
I’m assuming there are performance trade-offs behind this behavior—I’ve made similar calls on other UIs. But those trade-offs are usually applied to typing events (e.g., onInput, onKeyDown), not when applying or removing a label token. As it stands, the experience feels incomplete and heavier than it needs to be.
Steps to reproduce
- Go to Issues or Merge Requests list page.
- Apply a filter (e.g., label=bug).
- Observe that query params and the list view do not update until you click the Search button.
Observed behavior
- The filter text changes in the input, but results and query params remain unchanged.
- Nothing happens until you manually click Search.
Expected behavior
- Editing or removing a filter should trigger a search (API request) or at least update the query params.
- Even updating the query params would make it easier to refresh or share the page and have it reflect the current state.
Impact
- Users may think their changes “aren’t working.”
- Sharing links before pressing Search shows outdated filters.
- Refreshing before pressing search shows the previous state (see screenshare).
- The extra manual step makes the experience feel less fluid and creates UX friction.
Additional notes I understand the performance concerns—really, I do—but maybe a compromise would be updating the query params on edit. That way, a refresh or shared link would reflect the most recent state, even if the search request itself isn’t triggered automatically.gitlab-filter