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

Aperta
  • Qualcosa non va?
#34,123 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
67/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
angular, typescript
Ambito
frontend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
TypeScript
Stelle
25k
Fork
6.9k
Merge medio
2g 7h
PR unite (30g)
83

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di angular/components

Tutte le issue di angular/components

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.