Skip to content
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

bug(dialog): afterOpened not always emitted #26295

Open
1 task done
romainmoreau opened this issue Dec 19, 2022 · 2 comments
Open
1 task done

bug(dialog): afterOpened not always emitted #26295

romainmoreau opened this issue Dec 19, 2022 · 2 comments
Labels
area: material/dialog needs: discussion Further discussion with the team is needed before proceeding P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@romainmoreau
Copy link

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

14

Description

afterOpened is not emitted when the dialog is closed too fast.

Reproduction

I noticed this issue running some e2e tests but it also can be manually reproduced: basically just go to https://stackblitz.com/edit/afteropened-not-always-emitted-15 and double click on the button.

Expected Behavior

afterOpened should always emit a value before closing the dialog like in v14.

https://stackblitz.com/edit/afteropened-not-always-emitted-14

Actual Behavior

afterOpened is not emitted when the dialog is closed too fast.

https://stackblitz.com/edit/afteropened-not-always-emitted-15

Environment

  • Angular: 15.0.4
  • CDK/Material: 15.0.3
  • Browser(s): Firefox
  • Operating System (e.g. Windows, macOS, Ubuntu): Windows
@romainmoreau romainmoreau added the needs triage This issue needs to be triaged by the team label Dec 19, 2022
@crisbeto
Copy link
Member

Currently this is working as expected. afterOpened emits after the opening sequence has finished which doesn't happen if you close it too quickly.

@romainmoreau
Copy link
Author

It should be possible to simulate the previous behavior by combining beforeClosed and afterOpened but I think the behavior in v14 made more sense because it was simplier and more intuitive:

Diagramme sans nom drawio(2)

Maybe at least it should be mentionned somewhere because it silently breaks code migrated to v15 expecting afterOpened to be always emitted.

@wagnermaciel wagnermaciel added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent needs: discussion Further discussion with the team is needed before proceeding area: material/dialog and removed needs triage This issue needs to be triaged by the team labels May 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: material/dialog needs: discussion Further discussion with the team is needed before proceeding P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

No branches or pull requests

3 participants