Backlog : Poor performance on re-ranking item, the screen automatically scrolls rapidly

Issue Summary

We found there are two issue in the backlog view

1. When we click the item from the bottom of the display and move up to re-ranking, however, the browser starts scrolling down rapidly.
2. When we click and try to drag an item near the bottom of the display, select a row to move and then just drag the mouse, the screen automatically scrolls down quickly.

This is reproducible on Data Center: (yes)

Issue 1) Screen is skipped down, even the user moved the mouse slowly 

We try to drag and drop things to re-rank in Backlog view, and the screen automatically scrolls approximately 10-11 rows below starting point even though we didn't drag my mouse that far. It's incredibly hard to keep it from auto-scrolling the browser rapidly.

Please refer to the attached video clip.

Steps to Reproduce

1. Step 1. Go to any of the backlog view pages
2. Step 2. Select one item and drag it down slowly

Expected Results

The screen is moved the same as the user moves the items.

Actual Results

The screen is scrolled down quickly (jumped rows), even we didn’t move the mouse quickly.

Issue 2) Screen moves down, even the user tries to move up

I select of the item in the lower half of the browser window and try to move up to rank higher, however, the browser starts scrolling down rapidly, and it works ok a few seconds later.
Tried to move the item up again, and it worked fine.
Refreshed the page (press F5), and tried it again, and then the same issue occurred in the first try.

Actual Result: The user tries to move up the item, but the screen is scrolled down. It works better on 2nd time try. However, when the page is refreshed and do it again, the same issue occur.

Expected Result: Screen should move up when the user tries to move the item up.

Note:

• Tested on other browsers - Chrome / Edge / Safari, able to reproduce the issue.
• The same result is shown in all backlog views.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available