Unable to scroll to bottom on table with large amount of groups

[printpagestopdf]

Describe the bug Strange scrolling behaviour on larger amount of groups (1000). Nearly unable to scroll to bottom by mousewheel, unexpected jumping of group rows.

Tabulator Info

• Tabulator V5.5.0

Working Example https://jsfiddle.net/7oLv4ub9/3/

To Reproduce Scroll down the table by mousewheel

Expected behavior Should scroll down line by line

Desktop (please complete the following information):

• OS: Windows 10
• Browser Firefox, Brave
• Version FF114.0.1

**Additional Information Seems to be, that the problem does not occur if startet with groupStartOpen:true, or with unlimited tableHeight

[dannykhoo]

yes, i'm facing the exactly same problem

[FdvTerje]

We are having the exact same problem ourselves, your jsfiddle is exacly how our table is behaving

[DylanThomasFr]

Same problem on my end.

[andy-5]

We have the same problem in our application.

The issue seems to be when the vdom implementation starts to remove rows from the top (while scrolling down) here: https://github.com/olifolkerd/tabulator/blob/618e303fe50fdb8c6a7683a436c598ad7118447e/src/js/core/rendering/renderers/VirtualDomVertical.js#L153

If I comment this line, it works as expected in our case. But of course this change also defeats the purpose of the vdom.

Unfortunately, I haven't yet managed to track down the core problem with this code.

[andy-5]

The problem still happens with the recent 5.5.1 release.

[guidolongoni]

I can confirm that I encountered the issue with version 5.5.1.

After conducting a bisection of the repository, I identified the specific commit where the problem started to manifest: it has the hash 618e303fe50fdb8c6a7683a436c598ad7118447e.

Interestingly, this commit was tagged as version 5.5.0, while the merge of the 5.5 branch occurred in the preceding commit with hash 147045bec11431d2a775f7c1ad71776fb1a54b (which does not have the issue).

Upon initial inspection, it was challenging to pinpoint the exact change that triggered the problem, as there appears to be substantial code reformatting in that commit. In fact, it seems to be the typical final adjustment made before a release.

I will continue investigating to provide more detailed information about the specific changes in the commit that could be causing the issue.

[guidolongoni]

Hello everyone, While investigating the reported issue, I have created a simple HTML test file to reproduce the problem consistently. This could facilitate debugging operations.

https://jsfiddle.net/61mn8592/

To reproduce the issue:

• Save the above code as "test.html" on your local machine.
• Open the "test.html" file in your web browser.

The code generates a data array with 20 groups each consisting of a random number of records between 1 and 4. Both the grouping field and the value field are numbered sequentially starting with 1. The value field does not reset between groups, so it is unique.

I hope it can be helpful. kind regards

[guidolongoni]

Hi, I did some testing using the code in the previous post. Hoping that it will be useful for debugging I report two observations.

Observation 1: Scrolling skip phenomenon

I have noticed that by scrolling down a single wheel step, just before the reset-to-home event (in my case just before the second wheel step), and opening the last group, e.g., number 9 in the test shown above, Tabulator opens the group out of the visible space (let's call it Visible Row Window), but when I scroll down it skips ahead, skipping the entire next VRW. The phenomenon is repeatable and bidirectional: by turning the wheel up and down, the interval in question is constantly skipped.

Observation 2: Return position after opening group

Another peculiar phenomenon that can be consistently reproduced is the following: if I open one or more groups, in some cases the opening of the group triggers a return similar to the one that prevents getting to the bottom of the list. In this case, the return position is always just after the first open group.

[GranTracker]

Has there been any progress on this issue? For me, it makes using Grouping almost useless, unless all the groups are expanded. Using v5.5.2.

@olifolkerd - I'm surprised to not see any comments from you on this issue. Are you alive?

[zpp-andy]

I have the same problem with scrolling and also with opening the groups.

Possible solution One possible solution is to set the "renderVerticalBuffer (https://tabulator.info/docs/6.2/layout#virtual-dom-buffer)". But I think this is just a workarount and does not fix the error.

Short description Here is a short description of the problem. For clarification, I have created two fiddles in which you can test the behaviour.

Tabulator affected Version: >= 5.5.0 Previous Version (without issues): 5.4.4 Both problems are specific to version 5.5.0 and higher. These problems are also present in the latest version 6.2.1

5.5.0 https://jsfiddle.net/syh7kjrm/9/

The problems do not occur in version 5.4.4.

5.4.4 https://jsfiddle.net/5o09y8nd/20/

Issue 1: Vertical Scrolling in Grouped Views

Description In version 5.5.0, grouped views do not allow for vertical scrolling without manually setting a large renderVerticalBuffer. It appears that the automatic calculation of the buffer is not functioning correctly for grouped views.

Issue 2: Group Expansion Outside Initial Viewport

Description When expanding groupings that are outside the initial visible section of the window, the grouping expands but the view jumps to the beginning of the table instead of keeping the expanded section in the visible area.

---

I expect the same behaviour as up to version 5.4.4. I think that a change/optimisation of the render is responsible for the behaviour. (https://tabulator.info/docs/5.5/release#performance)