-
Notifications
You must be signed in to change notification settings - Fork 6.8k
fix(cdk/overlay): ensure error isn't thrown when many overlay items are closed from handler #20377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -71,15 +71,18 @@ export class OverlayOutsideClickDispatcher extends BaseOverlayDispatcher { | |
private _clickListener = (event: MouseEvent) => { | ||
// Get the target through the `composedPath` if possible to account for shadow DOM. | ||
const target = event.composedPath ? event.composedPath()[0] : event.target; | ||
const overlays = this._attachedOverlays; | ||
// We copy the array because the original may be modified asynchronously if the | ||
// outsidePointerEvents listener decides to detach overlays resulting in index errors inside | ||
// the for loop. | ||
const overlays = this._attachedOverlays.slice(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would prevent the error, but doesn't it have the potential of firing off the event for an overlay that's already closed? It may not be a problem in problem in practice since the Looking through the loop again, shouldn't we be breaking off as soon as we find an overlay to emit to? @jelbourn I was under the impression that we want to emit to the top overlay that has subscribers since that's how the keyboard dispatcher works too, but this will emit to multiple overlays. I think the It isn't something changed by this PR, but we may have to address it at some point before people start depending on it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It may fire off on an already closed overlay. An alternative to this would be to also check There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure about stopping at the first overlay (worth a follow-up discussion), but it does seem that we should check that the overlay is not already closed before emitting. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO we should be doing it, because the primary use case for this dispatcher is closing when the user clicks outside of an overlay. If we were to dispatch to all overlays, it would mean that when the user has multiple dialogs open at the same time, clicking on the top one will close everything else. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I suspect different use-cases would call for one or the other |
||
|
||
// Dispatch the mouse event to the top overlay which has subscribers to its mouse events. | ||
// We want to target all overlays for which the click could be considered as outside click. | ||
// As soon as we reach an overlay for which the click is not outside click we break off | ||
// the loop. | ||
for (let i = overlays.length - 1; i > -1; i--) { | ||
const overlayRef = overlays[i]; | ||
if (overlayRef._outsidePointerEvents.observers.length < 1) { | ||
if (overlayRef._outsidePointerEvents.observers.length < 1 || !overlayRef.hasAttached()) { | ||
continue; | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this go in an afterEach block in a separate describe block, if it needs to be run even if the test fails?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jasmine tests don't exit on a failed expect so the closing logic will run regardless.