Tabs component: scrollButtons="on" does not force buttons to appear

[srowe0091]

in Tabs component, scrollButtons="on" does not force buttons to appear

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

The documentation states

Left and right scroll buttons will be presented regardless of the viewport width.`

when setting the scroll buttons do not appear unless there is more items to show in the list

Expected Behavior 🤔

when setting the scroll buttons ALWAYS appear even if items do not go past parent width

Context 🔦

This issue could be resolved if the buttons would show, when the parent width becomes smaller. Currently if the width is wide to show all the items, no buttons would show, but if the parent width programmatically became smaller (like a persistent drawer), the scroll buttons will still not render unless a horizontal scroll wheel action is applied on the Tabs

Your Environment 🌎

Tech	Version
Material-UI	latest
React	latest
Browser	chrome

[oliviertassinari]

@mrowe009 Do you have a reproduction? What version are you using?

[srowe0091]

I am using the latest version of material UI and here is a recording of the issue

[oliviertassinari]

I fear we need a complete reproduction.

[srowe0091]

Here is a codesandbox showing the reproduction

https://codesandbox.io/s/material-demo-ridhn

if you make the browser tab wider until the arrow is gone, and then open the persistent drawer, you will see the behavior that the button does not appear unless a horizontal scroll action is applied on the tabs

[oliviertassinari]

@mrowe009 Thanks! It's a known limitation. It's the same underlying issue than with #9337. I would propose the following diff:

diff --git a/packages/material-ui/src/Tabs/Tabs.js b/packages/material-ui/src/Tabs/Tabs.js
index 0229813ba..15c3570bf 100644
--- a/packages/material-ui/src/Tabs/Tabs.js
+++ b/packages/material-ui/src/Tabs/Tabs.js
@@ -360,8 +360,9 @@ const Tabs = React.forwardRef(function Tabs(props, ref) {
     action,
     () => ({
       updateIndicator: updateIndicatorState,
+      updateScrollButtons: updateScrollButtonState,
     }),
-    [updateIndicatorState],
+    [updateIndicatorState, updateScrollButtonState],
   );

   const indicator = (
@@ -455,7 +456,7 @@ Tabs.propTypes = {
   /**
    * Callback fired when the component mounts.
    * This is useful when you want to trigger an action programmatically.
-   * It currently only supports `updateIndicator()` action.
+   * It supports two actions: `updateIndicator()` and `updateScrollButtons()`
    *
    * @param {object} actions This object contains all possible actions
    * that can be triggered programmatically.

Based on the issue history, it seems to have impacted a non-negligeable number of users. It seems that most go with the workaround:

window.dispatchEvent(new CustomEvent('resize'));

[srowe0091]

Using

window.dispatchEvent(new CustomEvent('resize'));

works as expected now. Even this works with a hacky solution, do you think there will be a fix for this in the future?

[oliviertassinari]

@mrowe009 What would you qualify as a good fix?

[srowe0091]

@oliviertassinari not having to dispatch an event manually, because I also have to wait for transition duration of drawer animation to finish open/close to then dispatch the event. Having the Tabs listening on width changes would be ideal, and self handling within Tabs component.

[oliviertassinari]

OK so you are looking for the ResizeObserver approach. It has a cost of 2 kB gzipped. We will bring this dependency once it can help more than it can harm. I don't know went it will be. So far, we manage to hold back for a year.

[srowe0091]

Okay no worries, as long as I have it working for now, and hopefully it doesn't break in the future, then it should be fine until there is more of a need for the ResizeObserver approach. Thanks for the help!