bug(material/dialog): exit animation "jumps" (shrinks, then snaps back) when close() is called inside a requestAnimationFrame callback — common in zoneless apps

Ouverte
  • Quelque chose ne va pas ?
#34,123 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
67/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
angular, typescript
Domaine
frontend

Piste de recherche

Start with MatDialogContainer._startExitAnimation() in the dialog container source and trace how it changes the open and closing classes. Reproduce the issue with the linked StackBlitz by closing from a requestAnimationFrame callback, then check the dialog animation tests for existing exit behavior. Done means the exit transition moves directly from open to closing without a frame in the class-less state.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

area: material/dialog needs triage
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

No response

Description

MatDialogContainer._startExitAnimation() removes mdc-dialog--open synchronously, but adds mdc-dialog--closing in a requestAnimationFrame callback:

this._hostElement.classList.remove(OPEN_CLASS);
if (this._animationsEnabled) {
  this._hostElement.style.setProperty(TRANSITION_DURATION_PROPERTY, `${this._exitAnimationDuration}ms`);
  this._requestAnimationFrame(() => this._hostElement.classList.add(CLOSING_CLASS));
  ...
}

If close() is called from a normal task (click handler, setTimeout, XHR callback), the rAF runs before the next paint, so the dialog goes straight from --open to --closing.

If close() is called from inside a rAF callback, the nested rAF is deferred to the next frame. One frame is painted with neither class. In that state the base styles apply: .mat-mdc-dialog-surface { transform: scale(0.8) } and .mat-mdc-dialog-inner-container { opacity: 0 }, both with a transition. The surface starts shrinking, then --closing arrives (transform: none) and it snaps back to full size before fading out.

In a zoneless app this happens without any explicit rAF in user code. The zoneless scheduler runs change detection via scheduleCallbackWithRafRace (setTimeout vs rAF, whichever fires first). Effects run during that tick (runEffect → runEffectsInView → ApplicationRef.tick → ChangeDetectionSchedulerImpl.tick), so a dialog that closes itself from an effect() is closed inside a rAF whenever the rAF wins the race. This is a common pattern when the close is driven by state, e.g. "close when the save request succeeded".

Because it depends on the race, it is intermittent. Measured on the reproduction below, by hooking classList.add/remove and recording the rAF frame timestamp of each change:

How close() is called Class-less frame painted Result
Inside a requestAnimationFrame callback 10 / 10 ❌ always jumps
From an effect() (zoneless, real mouse clicks) 2 / 4 ⚠️ intermittent
Directly in the click handler 0 / 10 ✅ clean fade-out

Example log for the rAF case: remove(mdc-dialog--open) happens in frame 92399.7, and add(mdc-dialog--closing) happens in frame 92424.8. In a real app, closing from an effect() after an HTTP response showed the glitch in 2 out of 6 attempts.

Not a regression as far as we can tell. The nested requestAnimationFrame was added in #26971 (v16), but it only becomes visible when close() runs inside a rAF callback, which zoneless change detection makes common.

Reproduction

StackBlitz link: https://stackblitz.com/edit/mat-dialog-close-in-raf?file=src%2Fmain.ts

The dialog component from the StackBlitz (the app is bootstrapped with provideZonelessChangeDetection()):

@Component({
  imports: [MatButton, MatDialogActions, MatDialogContent, MatDialogTitle],
  template: `
    <h2 mat-dialog-title>Example dialog</h2>
    <mat-dialog-content>Pick a way to close this dialog.</mat-dialog-content>
    <mat-dialog-actions>
      <button mat-button (click)="closeInRaf()">Close inside rAF</button>
      <button mat-button (click)="closeRequested.set(true)">Close via effect</button>
      <button mat-button (click)="dialogRef.close()">Close directly</button>
    </mat-dialog-actions>
  `,
})
export class ExampleDialog {
  protected dialogRef = inject(MatDialogRef<ExampleDialog>);
  protected closeRequested = signal(false);

  constructor() {
    effect(() => {
      if (this.closeRequested()) {
        this.dialogRef.close();
      }
    });
  }

  closeInRaf(): void {
    requestAnimationFrame(() => this.dialogRef.close());
  }
}

Steps to reproduce:

  1. Click "Open dialog", then "Close inside rAF". The surface visibly shrinks, jumps back to full size, then fades out. Every time.
  2. Click "Open dialog", then "Close via effect". Repeat several times. Some closes show the same jump.
  3. Click "Open dialog", then "Close directly". The dialog always fades out cleanly.

Slowing animations down in the DevTools Animations panel makes the jump easy to see.

Expected Behavior

The dialog transitions directly from the open state to the closing state, no matter which task or callback close() is called from.

Actual Behavior

When close() runs inside a rAF callback, one frame is rendered without mdc-dialog--open or mdc-dialog--closing. The surface starts animating toward scale(0.8) and then snaps back to transform: none when --closing is applied.

Related issues
  • angular/angular#57528 (canonical: consequences of macrotask scheduling). This is a related consequence of zoneless scheduling, but the intermediate state here is created by MatDialogContainer itself: --open is removed in one frame and --closing is added in the next. Angular's scheduler only determines where close() runs. The fix can stay local to the dialog container and needs no change to the scheduler.
  • Same class of zoneless timing bugs in other components: #29174 (virtual scroll flicker, fixed in #31316 by keeping the DOM write and the render in the same tick), #33837 (drag-drop blink), #33851 (select exit fade).
Possible fix

Either of these removes the class-less frame:

  1. Add CLOSING_CLASS synchronously in _startExitAnimation(). The rAF from #26971 is needed for the opening animation, because a freshly attached element has no previous computed style to transition from. On close, the element has already been rendered in the open state, so a synchronous class change starts the transition correctly. The duration custom property set in the same task is picked up as well, because transitions use the after-change style.
  2. Keep the rAF, but move the OPEN_CLASS removal into the same callback: 
    this._requestAnimationFrame(() => {
  this._hostElement.classList.remove(OPEN_CLASS);
  this._hostElement.classList.add(CLOSING_CLASS);
});
Environment
  • Angular: 22.2.4 (zoneless)
  • CDK/Material: 22.2.6. The same code is present on main.
  • Browser(s): Chromium-based
  • Operating System: macOS
Langage dominant
TypeScript
Étoiles
25k
Forks
6.9k
Merge moyen
2 j 7 h
PR mergées (30 j)
83

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de angular/components

Toutes les issues de angular/components

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.