Environment

Vuetify Version: 3.11.8
Vue Version: 3.5.28
OS: macOS 10.15.7 (current)

Steps to reproduce

1. Create a v-tabs component with show-arrows that receives tabs via a slot
2. Conditionally render enough v-tab items with v-if to overflow the container
3. Start with the v-if conditions evaluating to false (few or no tabs visible)
4. Reactively change the conditions so that many tabs become visible, exceeding the container width
5. Observe that the scroll arrows remain disabled despite the content now overflowing

Expected Behavior

Scroll arrows should become enabled whenever the total tab width exceeds the container width, regardless of whether tabs were present at mount time or added dynamically.

Actual Behavior

When v-tabs with show-arrows receives tab items via a slot, and those items are conditionally rendered with v-if, the scroll arrows do not update their enabled/disabled state when tabs are added or removed at runtime. The arrows remain disabled even when the tab list now overflows the container width.

Reproduction Link

https://play.vuetifyjs.com/#...

Other comments

Previous issue: This is a regression of #3643 — "v-tabs not displaying arrows (pagination) when adding dynamically tabs" — which was fixed in Vuetify 2 via #3728 by recalculating overflow on tabs change. That issue is now closed (April 2018), but the same behaviour has resurfaced in Vuetify 3 where the overflow detection mechanism was rewritten to use ResizeObserver instead of explicit recalculation.

Attempted workaround

Attempted using a MutationObserver on .v-slide-group__content to detect child-list changes, then briefly nudging the element's size (toggling padding-right: 0.1px) to force the internal ResizeObserver to recalculate overflow. This did not resolve the issue — the internal overflow state remained stale. Additionally, since VTabs renders a Fragment (multi-root component), accessing its DOM via $el is unreliable, making any workaround that targets internal elements fragile. There is no public method exposed on v-tabs or v-slide-group to trigger a recalculation, so there is no clean way to work around this from the consumer side.

Suggestion

Expose a public recalculate() or updateOverflow() method on VSlideGroup (and by extension VTabs) so consumers can trigger an arrow state refresh when they know the content has changed. Alternatively, VSlideGroup could internally use a MutationObserver on its content element to detect child-list changes and recalculate automatically — restoring the behaviour that PR #3728 provided in Vuetify 2.