“Jump to next unresolved thread” button has unexpected order with new threads
Summary
The jumping order of the “Jump to next unresolved thread” button works as expected if the threads were already present on page load. However, if the user starts a new thread and uses the jumping functionality, the order is not expected or natural.
For example: Thread A is at line 1. Thread B is at line 50. If one starts a thread C at line 25, the scrolling moves like this: A > B > C. The scrolling should move like this, as reading from top to bottom, regardless of when a new thread was started: A > C > B. If one reloads the page, the scrolling moves correctly.
Steps to reproduce
- Create a merge request with at least 1 changed file (preferably with plenty of changes so the scrolling is evident)
- Start a thread at the top of a changed file (thread A)
- Start a thread at the bottom of the same changed file (thread B)
- Reload the page
- Visit the Changes tab. Use the “Jump to next…” button. It should jump to thread A and then to thread B.
- Start a thread in the middle of the same changed file (thread C)
- Use the “Jump to next…” button. It jumps to thread A, then to thread B, and then to thread C.
- If the page is reloaded, the jumping order is now correct: A > C > B.
What is the current bug behavior?
It seems like new threads are inserted at the end of the “jumping array”, leading to a jumping order that is different from the “visual” top-to-bottom order in the Changes tab.
What is the expected correct behavior?
New threads should be added to the “jumping array” in a way that the jumping order is identical top the “visual” top-to-bottom order.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com