Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking in v7 - infinite loop triggered by expression interpolation in mat-tab-label template #14249

Closed
mflorence99 opened this issue Nov 23, 2018 · 1 comment · Fixed by #14251
Assignees
Labels
P2 The issue is important to a large percentage of users, with a workaround

Comments

@mflorence99
Copy link

mflorence99 commented Nov 23, 2018

Bug, feature request, or proposal:

Bug -- breaking change from v6 to v7

What is the expected behavior?

Under @angular/material 6.4.7 tabs coded like this works as expected:

<mat-tab-group>

  <ng-container
    *ngFor="let tab of tabs">

    <mat-tab>
      <ng-template
        mat-tab-label>

      <div>
        {{ tab.icon.split(' ') }}
      </div>

      </ng-template>
    </mat-tab>

  </ng-container>

</mat-tab-group>
import { Component } from '@angular/core';

@Component({
  selector: 'my-app',
  templateUrl: './app.component.html',
  styleUrls: [ './app.component.css' ]
})
export class AppComponent  {
  
  tabs = [
    { label: 'Tab A', icon: 'fas laptop' },
    { label: 'Tab B', icon: 'fas linux' }
  ];

}

NOTE: the example looks contrived because in reality I am coding something like <fa-icon [icon]="tab.icon.split(' ')" .... I have simply removed FontAwesome from the repro case.

What is the current behavior?

Under @angular/material 7.1.0 an infinite loop occurs rendering the tabs. In the Chrome debugger, you can hit PAUSE from the sources panel to confirm that the loop occurs during the tab rendering.

What are the steps to reproduce?

See https://stackblitz.com/edit/angular-qhqbxu?file=src%2Fapp%2Fapp.component.html. Fork the project and make the commented change. However, it is hard to debug in StackBlitz because once the infinite loop is triggered, there's no way of seeing what is going on and you can never get back to the original project. However, it is a good way of proving the problem exists.

So alternatively:

git clone https://github.com/mflorence99/qhqbxu.git
cd qhqbxu
npm install
npm run start

Then run http://localhost:4200/ in a browser.

If you replace this line in package.json:

"@angular/material": "^7.1.0",

with this line:

"@angular/material": "6.4.7",

Then the test case works correctly.

What is the use-case or motivation for changing an existing behavior?

The existing behavior is a bug that is a breaking change from v6 to v7.

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

Angular 7.1.0
Material 7.1.0
TypeScript 3.1.1

Chrome 70.0.3538.110
Firefox 63.0.3

@crisbeto crisbeto self-assigned this Nov 23, 2018
@crisbeto crisbeto added P2 The issue is important to a large percentage of users, with a workaround has pr labels Nov 23, 2018
crisbeto added a commit to crisbeto/material2 that referenced this issue Nov 23, 2018
Currently we trigger a change detection run when the content of the tab header changes. Since the `MutationObserver` callback can fire if the text node got swapped out, but the actual text didn't change, we could get into an infinite change detection loop if a poorly constructed data binding is used. These changes add a check that will only do extra work if the content has changed.

Fixes angular#14249.
jelbourn pushed a commit that referenced this issue Nov 28, 2018
Currently we trigger a change detection run when the content of the tab header changes. Since the `MutationObserver` callback can fire if the text node got swapped out, but the actual text didn't change, we could get into an infinite change detection loop if a poorly constructed data binding is used. These changes add a check that will only do extra work if the content has changed.

Fixes #14249.
jelbourn pushed a commit that referenced this issue Nov 28, 2018
…ged (#14251)

Currently we trigger a change detection run when the content of the tab header changes. Since the `MutationObserver` callback can fire if the text node got swapped out, but the actual text didn't change, we could get into an infinite change detection loop if a poorly constructed data binding is used. These changes add a check that will only do extra work if the content has changed.

Fixes #14249.
jelbourn pushed a commit that referenced this issue Dec 3, 2018
…ged (#14251)

Currently we trigger a change detection run when the content of the tab header changes. Since the `MutationObserver` callback can fire if the text node got swapped out, but the actual text didn't change, we could get into an infinite change detection loop if a poorly constructed data binding is used. These changes add a check that will only do extra work if the content has changed.

Fixes #14249.
josephperrott pushed a commit to josephperrott/components that referenced this issue Jan 14, 2019
…ged (angular#14251)

Currently we trigger a change detection run when the content of the tab header changes. Since the `MutationObserver` callback can fire if the text node got swapped out, but the actual text didn't change, we could get into an infinite change detection loop if a poorly constructed data binding is used. These changes add a check that will only do extra work if the content has changed.

Fixes angular#14249.
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants