bug(overlay): backdrop click and `open` input stop closing cdkConnectedOverlay once the host view is detached (only Escape still works)
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- angular, typescript
- Domaine
- frontend
Piste de recherche
Commencez par la reproduction StackBlitz liée, en vous concentrant sur le flux de RouteReuseStrategy et de ViewContainerRef.detach(). Examinez ensuite CdkConnectedOverlay dans @angular/cdk, notamment le comportement de _overlay-module-chunk.mjs décrit dans le rapport ; le travail est terminé lorsque les clics sur le backdrop et l’entrée open ferment l’overlay après le détachement de la vue hôte, comme c’est déjà le cas avec Escape.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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
When a component that hosts a cdkConnectedOverlay is detached (not destroyed) from the view tree while its overlay is open — for example via ViewContainerRef.detach(), which is exactly what RouterOutlet.detach() does when a RouteReuseStrategy.shouldDetach() returns true — the overlay becomes permanently stuck open and unresponsive to two of the three interactions users expect to close it with:
- Clicking the backdrop does not close the overlay.
- Programmatically setting the bound
[cdkConnectedOverlayOpen]input back tofalse(through any means — a signal, anasyncpipe, an explicitChangeDetectorRef.detectChanges()call) does not close the overlay. - Only pressing Escape closes the overlay.
Reading @angular/cdk source (_overlay-module-chunk.mjs), CdkConnectedOverlay only reacts to its [cdkConnectedOverlayOpen] input through the ngOnChanges lifecycle hook:
// CdkConnectedOverlay
ngOnChanges(changes) {
...
if (changes['open']) {
this.open ? this.attachOverlay() : this.detachOverlay();
}
}
ngOnChanges only runs when Angular's change detector actually visits the component's view. If that view has been detached from its view container (ViewContainerRef.detach()), Angular's CD walk no longer reaches it — so ngOnChanges never fires again, no matter how the open input is set afterward, including explicit, direct ChangeDetectorRef.detectChanges() calls on that specific component instance.
Meanwhile, the overlay's DOM (backdrop + panel) is portaled into a global overlay container appended to <body>, entirely outside the detached view's own DOM subtree. So the rendered overlay persists on screen even though the logical component that owns it is no longer part of the CD tree.
By contrast, the Escape key path bypasses the open input entirely:
// CdkConnectedOverlay._createOverlay()
overlayRef.keydownEvents().subscribe(event => {
this.overlayKeydown.next(event);
if (event.keyCode === ESCAPE && !this.disableClose && !hasModifierKey(event)) {
event.preventDefault();
this.detachOverlay(); // called directly on the OverlayRef/directive, not through the `open` input
}
});
This is a plain RxJS subscription held by the OverlayRef/CdkConnectedOverlay instance, so it keeps firing and calling detachOverlay() imperatively regardless of whether the host view is currently attached to the CD tree. This is why Escape is the only interaction that still works — it is the only one that doesn't route through ngOnChanges.
The backdrop-click path (OverlayOutsideClickDispatcher) is architecturally similar to Escape — it's a global document-level listener, independent of CD — but it only emits an outsidePointerEvents/backdropClick event. It is the consuming component's responsibility to react to that event by flipping its own open state, and that round-trip through the open input is exactly the mechanism that silently no-ops once the host view is detached. So backdrop click is detected, but has no observable effect.
RouteReuseStrategy and ViewContainerRef.detach() are public, documented Angular Router APIs — not an edge case or misuse. Any component built the idiomatic Angular way — driving overlay visibility through a bound @Input/signal rather than imperative OverlayRef calls — is exposed to this the moment it's used on a route that gets detached rather than destroyed. This affects CdkConnectedOverlay directly, and by extension anything built on top of it that follows the same input-driven-open pattern (custom menus, custom autocompletes, custom popovers, etc.).
The fact that Escape already has a CD-independent close path, while backdrop click and the open input do not, suggests this asymmetry is an oversight rather than an intentional design choice.
Suggested directions (not prescriptive):
- Give
CdkConnectedOverlay/OverlayRefa way to close in response to the host view being detached from change detection, mirroring the existingngOnDestroyhandling — e.g. reacting toViewRefdetachment, not onlyngOnChanges. - At minimum, make backdrop click behave like Escape: call
detachOverlay()directly on theOverlayRefinstance when a backdrop click is detected, rather than only emitting an event and relying on the host'sopeninput to round-trip back throughngOnChanges. - Document explicitly that
CdkConnectedOverlay-based components must not be detached (only destroyed) while their overlay is open, if a code-level fix is not pursued.
Reproduction
StackBlitz link: CDK overlay
Steps to reproduce:
- Open the StackBlitz above. It's a routed app with two routes,
/aand/b, using aRouteReuseStrategywhoseshouldDetach()always returnstrue(i.e.ViewContainerRef.detach()is called on navigation instead of destroying the component — a supported, documented use ofRouteReuseStrategy, commonly used to preserve scroll position, form state, or tab state across navigations). - On Page A, click "Go to Page B (in 5s)". This intentionally delays the actual navigation by 5 seconds (
setTimeout) — a test aid, not part of the bug — so there's a window to still interact with Page A before it's detached. - During that 5-second window, while still on Page A, click "Open overlay". A panel with a backdrop appears.
- Wait for the 5 seconds to elapse. Navigation to Page B happens and Page A's view is detached (kept alive, not destroyed) with the overlay still open.
- Try clicking the backdrop, or the "Close" button inside the overlay panel.
- Observe: nothing happens — the backdrop and panel are still visible on top of Page B and still block interaction with it.
- Press Escape: the overlay closes immediately.
Steps 5–6 are the bug: backdrop click and the in-app "Close" button (both driven by the same open input) silently do nothing once Page A's view has been detached, while Escape (step 7) still works.
Expected Behavior
The overlay should close consistently regardless of which interaction is used, and regardless of whether the host component's view happens to currently be receiving change detection.
Actual Behavior
Backdrop click and the open input binding silently do nothing once the host view is detached from the CD tree. Escape is the only interaction that still closes the overlay.
Environment
- Angular: 22.0.8
- CDK/Material: 22.0.2
- Browser(s): Chrome (latest)
- Operating System: macOS
- Langage dominant
- TypeScript
- Étoiles
- 25k
- Forks
- 6.8k
- Merge moyen
- 1 j 7 h
- PR mergées (30 j)
- 92
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de angular/components
-
area: material/datepicker P4
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
angular/components#33763 · 2 commentaires · 3 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
area: material/table P4
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
angular/components#33709 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
area: material/table docs gemini-triaged P4
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
angular/components#33455 ·
Les mainteneurs répondent en général sous 1 jour
-
area: material/core gemini-triaged P3
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
angular/components#33059 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
area: material/dialog P2
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
angular/components#30536 · 3 réactions ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de angular/components
Issues similaires
-
ADD openalgoOuvertetemplate
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 1 jour
-
factory-active factory-automatic task-bug-reproduction-success task-identify-harness-labels-done task-identify-issue-type-done
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
vercel/ai#21528 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug Needs: Triage :mag:
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
microsoft/fluentui-contrib#671 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
sveltejs/acorn-typescript#150 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100