Make issues search less finicky
What does this MR do?
- Tracks issues search pristine-ness, to ignore non-mutating keyups.
- Increase debounce wait on issues search execution from 500ms to 1000ms.
- Ensures issues search retains focus after search execution
Note: Issues search is being overhauled (https://gitlab.com/gitlab-org/gitlab-ce/issues/21747), so most (if not all) of these changes will no longer be used. But given that the overhaul has been pushed back a release (8.14?), it makes sense to do some quick fixes to improve UX in the meantime.
Are there points in the code the reviewer needs to double check?
Will adding autofocus to the search input create unforeseen problems?
Why was this MR needed?
-
At the moment, issues search is run on any keyup, even if search terms remain the same. This is an oversight that is both a tax on servers and an annoyance to users.
-
Searches are executed pretty quickly after a gap in keyups. It's too fast according to internal and enterprise customer feedback.
-
Focus is lost when a search is conducted, so you have to either tab to (any sane person would not do this, given our tab order) or reach for the mouse and select the input again.
These are all pretty heavily complained about issues that are, to quote community users, "rage-inducing" and "major accessibility issue[s]".
Does this MR meet the acceptance criteria?
-
CHANGELOG entry added -
Documentation created/updated -
API support added - Tests
-
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master(if you do - rebase it please) -
Squashed related commits together
What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/21503 https://gitlab.com/gitlab-org/gitlab-ce/issues/21984 https://gitlab.com/gitlab-org/gitlab-ce/issues/21597