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

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.

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