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

No way to intercept MdDialog close events #3893

Closed
benelliott opened this issue Apr 4, 2017 · 6 comments
Closed

No way to intercept MdDialog close events #3893

benelliott opened this issue Apr 4, 2017 · 6 comments
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix

Comments

@benelliott
Copy link
Contributor

Bug, feature request, or proposal:

There doesn't seem to be any way to intercept clicks outside a dialog that are intended to dismiss it. This can be desirable if, for example, the user has made some changes but has chosen to click outside the modal instead of clicking the "confirm" button.

The only way to intercept dialog close requests currently is to set disableClose: true in the dialog config and then to wire up the dialog action buttons to perform this logic when clicked.

What is the expected behavior?

There should be some way to intercept and cancel close events that come from the user clicking outside the dialog.

What is the current behavior?

There are only two possible scenarios - either

  1. the user cannot click outside the dialog at all, or
  2. clicking outside the dialog will always dismiss the modal

I suppose one workaround would be to allow the modal to be dismissed, but check and reopen it afterwards if necessary, but this would be clunky.

What are the steps to reproduce?

Create a modal without setting disableClose: true and try to intercept these close events.

What is the use-case or motivation for changing an existing behavior?

I feel that it is detrimental to the UX of the dialog not to allow the user to click outside of it to close it, however there should be some way to cancel these events if they were performed by mistake. Otherwise this could lead to an anti-pattern where the behaviour of dialogs are consistent across an app: some are dismissible, as they don't involve editing valuable data, while some are not as the developer doesn't want to take the risk that the user might accidentally dismiss them.

Which versions of Angular, Material, OS, browsers are affected?

Angular 4/Material 2 beta 2/Windows 7/Chrome 57

Is there anything else we should know?

This might issue might be a more general discussion about dialog dismissal behaviour than a simple bug.

@willshowell
Copy link
Contributor

@fxck has been pushing for this for a while and has a PR for it here #3460

@jelbourn jelbourn added the feature This issue represents a new feature or feature request rather than a bug or bug fix label Jun 8, 2017
@remillc
Copy link

remillc commented Oct 18, 2017

@benelliott, you can disable click outside the dialog, more exactly clicks on the backdrop, using the css property pointer-events:

.mdc-dialog__backdrop {
	pointer-events: none;
}

@willshowell
Copy link
Contributor

This should be solved by #6682. The gist of it is that, if you want to intercept closing of the dialog,

  1. set disableClose: true
  2. subscribe to backdropClick() and keydownEvents() to detect backdrop clicks or potential ESCAPE keydowns
  3. do whatever
  4. close manually when you're ready

@emilio-martinez
Copy link
Contributor

@benelliott it looks like this is resolved as per @willshowell's PR, correct?

@jelbourn
Copy link
Member

Going to close this since I believe the idea of "preventing dialog from closing" works today based on the aforementioned work.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix
Projects
None yet
Development

No branches or pull requests

5 participants