[Tabs] Ink bar does not update when container resizes

[rbleuse]

Bug, feature request, or proposal:

Bug :
Add stretched tabs in a sidenav container with side mode.
When the sidenav is resized with dynamic content (ie sidenav labels are translated), the md-ink-bar is not resized
That happens too with md-tab-nav-bar and full width tabs

What is the expected behavior?

md-ink-bar should be resized

What is the current behavior?

tabs are well resized but not md-ink-bar

What are the steps to reproduce?

plunkr :
https://plnkr.co/edit/q80nul7KYS8sJ0e8vwwi?p=preview
stackblitz :
https://stackblitz.com/edit/angular-material2-issue-6efd2m?file=main.ts

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

ng 5.1.1
material 5.0.1
chrome 61

Is there anything else we should know?

[finalxcode]

+1

[rbleuse]

Is there any news about this ? I updated the plunker to latest angular & material2, and still same issue.

BTW it seems now that the sidenav is overlapping tabs

[anton-dragon]

Is there any workaround for this issue?

[alexw10]

Hope this gets looked at soon, tried a few things to resolve this but no luck.

[Marshal27]

The issue to me appears that the _realignInkBar is only triggered by the _viewportRuler which is controlled by a window resize event. I attempted playing around with MutationObserver but unfortunately that is not able to monitor the values in the _tabListContainer.nativeElement that we would need for that to work.

Without a way to actively monitor either the clientWidth or offsetWidth values and trigger either an event or some type of changeDetection when those values are modified... I was stuck with the following hacky solution that allowed me to realign the inkBar after my resizing event. Not pretty but got the job done in my scenario.

Hope this helps others looking for a workaround to this issue.

setTimeout(() => {
window.dispatchEvent(new Event('resize'));
}, 100)

[rbleuse]

I personally fixed this issue in my project (i'm using a sidenav) by calling the private method _alignInkBar :

@ViewChild('matTabs') matTabs: MatTabNav;

ngOnInit() {
    this.sidenavService.getSidenav().onOpen
    .pipe(takeUntil(this.ngUnsubscribe))
    .subscribe(() => {
      this.alignInkBar();
    });
    this.sidenavService.getSidenav().onClose
    .pipe(takeUntil(this.ngUnsubscribe))
    .subscribe(() => {
      this.alignInkBar();
    });
  }

  // FIXME delete when https://github.com/angular/material2/issues/6130 is fixed
  alignInkBar() {
    setTimeout(() => {
      this.matTabs._alignInkBar();
    }, 0);
  }

  ngOnDestroy() {
    this.ngUnsubscribe.next();
    this.ngUnsubscribe.complete();
  }

[Marshal27]

@spanja thank you for sharing, your workaround is much more elegant!

[dannye]

@spanja Thanks for your workaround. It appears _alignInkBar() has been renamed to realignInkBar()

An issue I have is that the mat-tab-group is in a router-outlet which is inside the mat-sidenav-content
So the mat-sidenav that causes the buggy mat-ink-bar isn't accessible in the script for the component that contains the mat-tab-group

For now I'm doing something similar to @spanja except I'm using ngDoCheck() instead:

ngDoCheck() {
  this.matTabs.realignInkBar();
}

The major downside to this is that the mat-ink-bar doesn't get corrected until the mat-sidenav is finished opening/closing. This delay looks extra bad because I have two mat-tab-groups in that component and the second tab group works correctly because its mat-tab-header-pagination-controls-enabled is always present, and the mat-ink-bar is always correctly animated if pagination controls are enabled, regardless of the changing width of the container.

A minor downside to this is that the mat-tab-group which uses realignInkBar() flickers between having its pagination controls enabled and disabled very sporadically, even when there is enough room such that the pagination controls should not be enabled at all.

Is there any news on this bug?
Or any advice on improving the downsides to this workaround?

Thanks

EDIT:
The sporadic flipping between pagination controls being enabled/disabled only happens when the selected tab is the right-most tab. It also isn't really a downside to the workaround, but actually a bug caused by mat-stretch-tabs

[pmilic021]

There is same issue with pagination arrows, if the container (not the window itself) is resized, pagination arrows won't recalculate, so I used similar hack for the time being:

@ViewChild(MatTabGroup) matTabGroup: MatTabGroup;

private updatePagination() {
    setTimeout(() => {
      this.matTabGroup._tabHeader.updatePagination();
    }, 0);
  }

[JGSolutions]

@pmilic021 When do you call the method updatePagination()?

[pmilic021]

@JGSolutions I had some animation for enlarging a div to full-screen mode, so I ran it at the end of the animation:
<div class="content-container" [@fullWidth]="isFullScreen" (@fullWidth.done)="updatePagination()">

[phillipe-barbosa]

+1

[IgorKurkov]

+1
wrote workaround here #3048 (comment).
the same problem.

[pcnate]

The ink bar should have left and width set as a percentage. To avoid issues when tabs overflow the visible space the width of the ink bar parent should match the total space for the tabs and it should be moved left right with overflow hidden when tabs change.

For example, when you have 4 tabs. The element.style set by the library should reflect the following:

.mat-ink-bar  {
  left: 50%;
  width: 25%;
}

This would yield an ink bar that resizes with no API hacks that shows under the 3rd tab. Having 2 tabs to the left would be calculated with left = tabIndex * ( 1 / numberOfTabs ) and width = 1 / numberOfTabs

Additional styling would be required to deal with tabs that overflow the visible space.

[bierzorutas]

Same problem here... still present after more than 3 years

[andrewseguin]

This is probably unlikely to be fixed since it is not an issue in the experimental MDC tabs version

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}