Table: Scroller does not respect flex scrollHeight when number of rows changes

[MikeMatusz]

Describe the bug

In the Table, when using virtual scroll with a scrollHeight="flex", if the data source is changed and there are not enough rows to fill the viewport, the horizontal scrollbar will display immediately below the last visible row instead of at the bottom of the flex container. Resizing the window fixes it.

Environment

Seen on Windows and Mac OS, multiple browsers.

Reproducer

https://stackblitz.com/edit/nimzpo?file=src%2Fapp%2Fdemo%2Ftable-column-resize-expand-mode-demo.html

Angular version

16.2.7

PrimeNG version

16.4.1

Build / Runtime

Angular CLI App

Language

TypeScript

Node version (for AoT issues node --version)

20.7.0

Browser(s)

All

Steps to reproduce the behavior

1. Go to the StackBlitz example linked above.
2. Resize a column to make it larger so a horizontal scrollbar appears.
3. Note that the scrollbar is not at the bottom of the container as expected.
4. Resize the window.
5. Note that the scrollbar has moved to the expected position.
6. Change the number of rows to 3 using the provided input and button.
7. Note that the scrollbar again appears in the incorrect position.

Changing the value to any number that doesn't match the "default height" calculated by the scroller initially and on window resize will result in the Scroller using a pixel height in calculateAutoSize (here) when it should always use scrollHeight if set to 100%. If you change the number of rows back to the same value it was set to last time the window was resized, the scrollbar will use the correct height.

Expected behavior

The horizontal scrollbar should always be at the bottom of the container when using scrollHeight="flex".

[AzatKhalilov]

Yep. I have the same problem. Sometimes height is set right in 100%, sometimes some value in pixels. I have version PrimeNG - 17.18.0

[mehmetcetin01140]

Hi,

So sorry for the delayed response! Improvements have been made to many components recently, both in terms of performance and enhancement. Therefore, this improvement may have been developed in another issue ticket without realizing it. You can check this in the documentation. If there is no improvement on this, can you open a new issue so we can include it in our roadmap?

Thanks a lot for your understanding! Best Regards,

[MikeMatusz]

Currently using v17.18.12, and after removing my workaround I haven't been able to reproduce the issue. Thanks for the fix!