When enough tabs are used that pagination behavior is triggered, and the user changes the viewport size, a number of strange things start happening:
1) the Tabs component seems to switch between mobile (scrolling) mode and desktop (paginated) mode somewhat indiscriminately if the Tabs property mobile is set to true or not set at all.
2) the number of tabs that should fit on each page seems to be miscalculated, but only sometimes - when this occurs, if the pagination controls are used, sometimes there will be tabs missing altogether.
my best instructions on how to (somewhat) reliably reproduce this issue are as follows:
1) load my codepen example
2) resize viewport to a size small enough for the tabs to go into paginated mode (0 through 5 displayed)
3) reload the page
4) click into the second "page" of tabs (6 and 7 displayed)
5) click one of the tabs on the second page (tab 6)
6) resize the window a bit - as you move slowly it will flicker between showing an appropriate number of tabs and only 1 or two.
7) stop resizing when only one tab is showing
8) paginate through the tabs back to 0 - it continues to show only one tab per page
9) paginate forward through the tabs and it only reaches tab 4, with no more "next" button





codepen example: https://codepen.io/phlare/pen/MVmwez
This issue was first discovered in developing our guidebook product at hostfully, but I've worked around it by forcing the tabs into mobile mode 100% of the time using the mobile property of the Tabs component and adding some extra css to make the mobile version of the tabs work inside a container that isn't 100vw. and some javascript love to bounce the slider a bit so it's obvious that there are more tabs.
I'm actually pretty happy with my workaround and like it better than the paginated version anyway, so this certainly isn't a showstopper bug for me or anything, but I just wanted to get this issue raised properly.
cheers
@mlaursen Any sign of fixes/workarounds/resolutions to these issues?
@kanso-michael Sorry, not yet. There is a big problem with how I am determining which elements can be visible since I actually remove them from the DOM and never add them back or do recalculations after a resize.
This bug isn't a huge priority for me though since I personally don't use Tabs in work or fun projects much. Right now I am working on fixing the behavior, styles, bugs, and ES6 imports for my components in almost this order (I've already completed some of these):
This is my priority list right now, but I am going to be writing an issue within the next few days with an updated roadmap of what I am planning on doing and how to make this project not stagnate while I'm working on stuff. It'll also be a good time for any other input from users/contributors of this library to give feedback about priorities. I think one of the biggest problems I'm running into right now is that I am working off of my own priority list instead of the community's (and I haven't made this project super contributor friendly yet) as well as feeling a bit of a burnout with the amount of work that needs to be done + full time job. So if there are things that are a lot more important than the fixes I want to do, the order might change a bit and do more patches until it's at a good state.
Most helpful comment
@kanso-michael Sorry, not yet. There is a big problem with how I am determining which elements can be visible since I actually remove them from the DOM and never add them back or do recalculations after a resize.
This bug isn't a huge priority for me though since I personally don't use Tabs in work or fun projects much. Right now I am working on fixing the behavior, styles, bugs, and ES6 imports for my components in almost this order (I've already completed some of these):
This is my priority list right now, but I am going to be writing an issue within the next few days with an updated roadmap of what I am planning on doing and how to make this project not stagnate while I'm working on stuff. It'll also be a good time for any other input from users/contributors of this library to give feedback about priorities. I think one of the biggest problems I'm running into right now is that I am working off of my own priority list instead of the community's (and I haven't made this project super contributor friendly yet) as well as feeling a bit of a burnout with the amount of work that needs to be done + full time job. So if there are things that are a lot more important than the fixes I want to do, the order might change a bit and do more patches until it's at a good state.