Scrollable TabView Shows right scroll button on initialization regardless of TabPanel header overflow

[KeithGillette]

I'm submitting a ... (check one with "x")

[X] bug report => Search github for a similar issue or PR before submitting
[ ] feature request => Please check if request is not on the roadmap already https://github.com/primefaces/primeng/wiki/Roadmap
[ ] support request => Please do not submit support request here, instead see http://forum.primefaces.org/viewforum.php?f=35

Current behavior
When [scrollable]=true, the p-tabView component displays the right scroll button on initialization even when no TabPanel header overflows the TabView.

Expected behavior
The right scroll button should not appear when there is no TabView TabPanel header overflow.

Minimal reproduction of the problem with instructions
Stretch the TabView page of the PrimeNG component showcase across multiple displays or zoom the browser page out until all 50 tabs are visible. The right scroll button will be visible even though there is no TabPanel header overflow.

What is the motivation / use case for changing the behavior?
The UX is inconsistent: Given that the left scroll button does not appear when there are no tabs overflowing the left margin of the TabPanel, the visibility of a scroll button provides an affordance indicating the availability of hidden scrollable content, reinforced by the TabView behavior once the scroll buttons have been pressed and then the viewport size changed to eliminate content overflow, which causes the right scroll button to disappear. The visibility of the right scroll button on TabView initialization regardless of content overflow is inconsistent with the aforedescribed UX.

Please tell us about your environment:

• PrimeNG version: 12.1.1 & 12.2.0-rc.1

• Browser: Chrome 93.0.4577.82 | Firefox 91.0 | Safari 14.1.2

[draco2007]

The problem exists also in the current version 13.3.3.

It is even worse. If you have scrollable true, scroll to the right untill the button disappears, resize the browser window, so all tabs fit on the screen and then make the browser smaller again, the "scroll-right" button keeps hidden and there is now way to reach the overflown tabs again.
This is a huge problem for us.

[alejandra-moreno-espinar]

Hi! I encounter the same issue with version 13.4.1. In which version can I find a fix for this bug? Thanks!

[KeithGillette]

This bug has not been fixed as of the latest PrimeNG release, 14.1.2. Since the component showcase now enforces a fixed width for the TabView display, making it impossible to demonstrate the problematic behavior, I have created a Stackblitz reproduction.

[alejandra-moreno-espinar]

Not sure if I understood correctly, but I still see the error on your example. Simply set the tabs to 4 and the right navigation arrow is there even though the 4 tabs fit in. See attached print screen.

[KeithGillette]

Yes, demonstrating that the error still exists in the latest version of PrineNG was the point of creating the Stackblitz reproduction because it’s no longer possible to see the problem just by looking at the PrimeNG component showcase, as it was when I created this issue.

[mertsincan]

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 reopen the issue so we can include it in our roadmap?
Please don't forget to add your feedback as a comment after reopening the issue. These will be taken into account by us and will contribute to the development of this feature. Thanks a lot for your understanding!

Best Regards,

[KeithGillette]

@mertsincan—Authors cannot reopen their issues when closed by a repository collaborator, so I ask that you please reopen this report, as this bug still exists as demonstrated in the recently posted reproduction.

[imolina-tcman]

Hi,

I am using PrimeNG 13.1.0, and I see that the issue remains unresolved. I have checked the website, and the example uses version 16.0.0-rc.1, but from what I have seen, it still displays the right scroll button even when there is no overflow.

Is there any plan to review this and fix it in future versions?
Thank you very much.

[TS-Tino16]

This should be fixed with the following pull request, right?
#12913

For now I applied the following workaround, as mentioned here:
#11684 (comment)

[sagunpandey]

I went with a temporary hack on my local project to get around the issue.

parseInt is the root cause while calculating the forwardIsDisabled flag. I retried the reference of TabMenu:

I override the updateButtonState method and copied over the implementation of the function while making the small change.

The library maintainer should do the same. Update the parseInt to Math.ceil. parseInt will just omit the decimal values. Math.ceil will round it off to the nearest next integer value which will then satisfy the condition.

[Nabeeh-AlSawaf]

Update the parseInt to Math.ceil. parseInt will just omit the decimal values. Math.ceil will round it off to the nearest next integer value which will then satisfy the condition.

the previous reply is almost fully correct, rounding floating points will always result in errors, the most agreed on solution for such problem is (having the absolute difference of 2 value less than Epsilon) where epsilon is minimum acceptable value to consider 2 numbers the same
resulting in
this.tabMenuRef.forwardIsDisabled = Math.ceil(scrollLeft) === scrollWidth - width;
to
this.tabMenuRef.forwardIsDisabled = (scrollWidth - width) - scrollLeft < 1;

in my application 1px difference is negligible u can lower it as much as u need
an even more mathematical accurate answer would be
this.tabMenuRef.forwardIsDisabled = Math.abs((scrollWidth - width) - scrollLeft) < Number.EPSILON;