Maintain vertical scroll position after an external changeset is applied from live updates

[matsbryntse]

Description from duplicate #7410 by @bmblb :

In the current implementation grid is trying to keep top scroll position during refreshes and updates of various sorts. It works well when number of renderable records does not change. If it does (records added, removed, data is filtered or filter is removed), then keeping scroll position becomes a poor choice.
What we really need is doing our best keeping user's context. If new rows were added at the top while we're looking in the middle, we should keep seeing same rows.

Suggestion:
Instead of keeping scroll position, we should keep visual position of the first visible row. Or maybe one in the middle? Or probably we need a fancier logic to determine which scroll position will show as much of the old view as possible, i.e. setting view to show as many earlier visible rows as possible.

[emilschutte]

Additional detail from the customer:

Here's some more detail around how we're thinking about maintaining the view:

Off screen changes - Changes done by others that do not apply to what I, as a listener, currently have on my screen should not affect my view.

• If rows above or my current view are deleted, the rows in my view should not move up
• If rows are inserted above my current view, the rows in my view should not move down.
• If tasks are indented / outdented above my current view the rows in my view should not move up or down.
• If rows not on my screen get updated values, there should be no change to my screen.

On screen changes - Changes done by others that affect what is on my screen should get applied to my view in accordance with the sorting, filtering, expand / collapse and first indent requirements already outlined.

• If rows are deleted in my view, then the rows beneath should move up by the number of rows in my view that were deleted, rather than by the total number of rows that were deleted, which may include rows not in my view.

  • Imagine two clients on the same project. The project has 100 tasks. One client is showing tasks 1 to 30 in their display. The second is showing tasks 21 to 50. There is an overlap between what the two clients see. Now imagine the first client deletes tasks 11 through 30, so a total of 20 tasks. On the second client, this change affects tasks 21 through 30 which are the only ones in view, so a total of 10 tasks. The expectation on the second client is that tasks 21 through 30 get deleted and all the rows in view shift up by 10 rows, and not the full 20 rows being deleted,. The net effect is to have what was task 31 now appear at the top the second client's display rather than what was task 41.

• If rows are inserted in my view, then the rows beneath the insert in my view should move down.

• If rows on my screen are indented beneath a parent not on my screen, these rows should disappear and the space left behind should be filled with rows from below

• If rows on my screen are indented beneath an existing parent also on my screen, the indenting should occur on my screen with my parent maintaining its expanded or collapsed state

• If rows on my screen are indented beneath a row on my screen creating a new rollup, the indenting should occur on my screen, the new parent should appear collapsed, and the space left behind should be filled with rows from below.

• If rows on my screen are getting updated values, these values should update on my screen once committed.