Tabulator vertical scroll skipping / jumping

[jarb99]

Hi There,

I am a big fan of Tabulator, thanks for the great work! There is a scrolling issue I have not been able to overcome and cannot see another bug report for. This is the only issue we have found that is preventing us adopting in our app so super keen to resolve.

Description:

• When scrolling up in a table with several rows, the table skips suddenly jumping down.
• This behavior seems to be triggered by a window / container resize although not always.
• This behavior can be reduced some of the time with table.redraw(true) as recommended in the docs -This is a problematic band aid as it will reset the scroll to the top of the table which interrupts user experience
• The tabulator internal debug log reports this as a single downwards scroll event, despite no downward scroll input from the user.
• The skipping is much worse for rows that are spread over multiple lines using ‘textarea’ or custom formatter (our intended use).
• I have reproduced this on multiple devices, Firefox, Edge & Chrome.

Tabulator Info: version 5.1

Desktop: Windows 10/11, OSX

Working example: • I have found this issue appears on the Tabulator website in the vertical DOM example (Gif of behaviour attached). This seems easier to reproduce behavior than the code sandbox example. • Codesandbox: https://codesandbox.io/s/still-hooks-39032m?file=/src/App.js

gif showing example of vertical scroll skipping after window resize

Steps to reproduce

• Go to tabulator example website, Virtual DOM – vertical example.
• Scroll to bottom of table.
• Resize browser window horizontally, forcing tabulator container to resize
• Start scrolling up. Sometimes it takes a couple of goes to reproduce the behavior. Is most evident using the middle mouse button click to lock smooth scrolling in direction of cursor.

Expected behaviour

• Smooth scrolling. Perhaps there is an internal fix Tabulator could incorporate which detects this scroll misfire

[jarb99]

hello @olifolkerd did you see this one? perhaps it is a mystery? there is no solution or suggestion from the community so we are sadly looking to migrate away from tabulator for our mvp.

[olifolkerd]

Sorry for not getting back to you, I did see this one. But between the website rebuild and the 5.2 release I only have so much time to respond to issues at the moment. You won't have received any community help on this one as I'm afraid there is no quick fix.

Thanks for the kind words and detailed report, that is very helpful. It is currently on the list to look into for the next release later this month, so with any luck I will have a fix by then, but I try to make sure that the feature releases aren't held up if bugs are too complex to resolve, so they will often be pushed to their own patch release. You are welcome to submit a PR with a fix yourself if you need it urgently.

If you feel unable to wait for an update then the choice to move is entirely yours. Open source free to use projects are not suitable for every usage case, if you want immediate response to your issues then paying for a different licensed library may be the right call for you. This library is provided as is, with no guarantees or service level agreements.

But you won't find many open source tools that will instantly fix issues, as you will see some issues have had to wait much longer for resolution, this is a tool built in my free time and maintained mainly by one person with occasional community support, there is a limit to the amount that can be done at once.

I am currently in the middle of working on the 5.2 update, working through many requested features and so have taken a temporary pause on patch releases as I do for every minor release. Having cleared off over 40 issues in this upcoming release so far.

Just so you are aware of the process, I fit in fixes when I have the free time to do them, around my other commitments and off time and prioritise based on level of community engagement and apparent severity. In this case this is a minor visual glitch, only present under certain circumstances, with with no impact on table data, and no additional community engagement and so has not been as high as others that directly blocked table functionality.

Cheers

Oli

[jarb99]

Awesome thanks @olifolkerd, confirmation that this is to be resolved on the horizon is all we were after. Will feed this back to the team. Your work on this is much appreciated and we will be considering the commercial license re the support requirement if we proceed. Thanks again, love what you have created :)

cheers jack

[blankbadge]

Just adding this as a comment to this existing issue, because I'm assuming it is the same problem. But here is another testcase demonstrating this vertical scroll jumping issue. I can also see it on the Tabulator webpage examples, like @jarb99 mentioned.

In my testcase, there is a certain way to trigger the behavior -- it doesn't happen every time you scroll up.

https://jsfiddle.net/blankbadge/rocanuxh/

I saw this using Tabulator 5.2.3 and Chrome 100 on Windows 10:

(1) Scroll vertically all the way to the bottom. (2) Scroll horizontally part way to the right. (3) Now scroll vertically back up. When you do, you should see that the rows 'jump' partway back down again on each scroll, losing some of the scroll progress and causing a jittery visual effect. This can be seen with both keyboard scroll or click-and-dragging the scrollbar (in which case the mouse pointer starts to get ahead of the scrollbar as it continues to jump back down).

One thing to note is that I don't see the behavior if I simply scroll down and then back up. I have to do step (2) where I engage the horizontal scrolling. After that, scrolling vertically up consistently shows the issue.

Thanks! -blankbadge

[olifolkerd]

Thanks for the additional feedback. I know exactly what is causing this issue, it is when there are variable height rows that differ from the calculated average. when they appear above rendered rows (because of a fast scroll that skips part of the table) the then cause the position of all elements below them to shift which they causes the skipping effect.

This isnt a problem normally because most rows are made visible at the bottom of the table in the buffer zone and the padding buffer of the virtual dom is adjusted to compensate, but when they are above the data instead of below it causes this shift.

It is on the list to fix and i will resolve it when i get round to it.

[VictorioBerra]

I just ran into this today with v5.3.4 I set a height on both my table, and my inner-table. Any ideas are welcome.

[silverma]

Thanks for all the work you do! I just wanted to vote this one up if it will help. Thanks again!

[antman3351]

Hey @olifolkerd,

I've just ran into this issue using a table with 1 collapsed row of varying height

I noticed in the VirtualDomVertical module in _removeTopRow the row height is always the same even though the rows are not the same height.

I think there's an issue where the column height isn't recalculated after the rows are collapsed. Trying to debug the issue, I added a call to recalculate the row height in the ResponsiveLayout module and this seemed to give me 99% improvement in skipping. Is this a good place to add the call and or should it be added in other places ?

I noticed that the rowFormatter example on the tabulator website also has jumping issues while scrolling, could it be the same problem?

Cheers, Antonio

[osama294]

Hi @olifolkerd, any updates on this one?

[jabatista14]

Hi @olifolkerd, would this be fixed soon?