bug(MatSnackBar): Opening a second snackbar doesn't close the first one in Global Error handler

[ErikNijland]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

12.0.0

Description

Opening the SnackBar more than once from a global error handler (https://angular.io/api/core/ErrorHandler) does not close previously opened SnackBars.

Reproduction

Steps to reproduce:

1. Go to https://stackblitz.com/edit/angular-ivy-1uxyez
2. Two errors are triggered, and two snackbar elements are in the DOM. Running document.querySelectorAll('.mat-snack-bar-container') will return both of them.

If you trigger a single error instead. This can be done by uncommenting line #13 of app.component.ts. It does work.

Expected Behavior

• The first snackbar is closed
• The second snackbar is opened

Actual Behavior

• Both snackbars are in the DOM
• The text is not readable, probably because of the overlapping DOM elements.

Environment

• Angular: 13.2.2
• CDK/Material: 13.2.0
• Browser(s): Chrome 98
• Operating System (e.g. Windows, macOS, Ubuntu): macOS

[crisbeto]

I spent some time looking into this and it looks like the problem is that the errors thrown during change detection prevent the snack bar animation from running which in turn prevents the proper cleanup. While this can be fixed and I agree that having multiple snack bars there at the same time is problematic, I'm not sure that using the snack bar for template errors is a good idea to begin with. The problem is that the example above is going to throw an error on every change detection, while the NgZone.run call in the error handler and the snack bar animations are going to trigger new change detection runs which then try to open new snack bars, causing an infinite loop.

[wagnermaciel]

@crisbeto Can you remove the needs triage label from this and apply the correct priority label if this is a real issue

[ErikNijland]

I'm not sure that using the snack bar for template errors is a good idea to begin with.

I fully agree, it's a simplified example where I could easily trigger two errors. In our real app two different errors occur based on an API response.