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

Allow changing of disableClose property for dialog while dialog is open #3938

Closed
harrymitchinson opened this issue Apr 6, 2017 · 2 comments · Fixed by #4964
Closed

Allow changing of disableClose property for dialog while dialog is open #3938

harrymitchinson opened this issue Apr 6, 2017 · 2 comments · Fixed by #4964
Assignees
Labels
feature This issue represents a new feature or feature request rather than a bug or bug fix P5 The team acknowledges the request but does not plan to address it, it remains open for discussion

Comments

@harrymitchinson
Copy link

Bug, feature request, or proposal:

Feature request

What is the expected behavior?

If a dialog is opened with disableClose as false, being able to change disableClose to true from within the dialog's component making it so dialog cannot be closed by clicking outside of the dialog area.

What is the current behavior?

Updating disableClose does not do anything. If the dialog is opened with disableClose as false and then disableClose is set to true, you can click outside the dialog and the dialog will close.

What are the steps to reproduce?

Change this.dialogRef.config.disableClose = true; from within a dialog component
Example

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

Using dialog for registration form. After registration submit the form changes to a confirmation code input which the user should not be able to navigate away from without registering again.

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

"@angular/common": "^4.0.0",
"@angular/cli": "1.0.0",
"@angular/material": "^2.0.0-beta.2"

All OS & only tested Chrome but would assume all browsers

Is there anything else we should know?

No :)

@jelbourn jelbourn added feature This issue represents a new feature or feature request rather than a bug or bug fix P5 The team acknowledges the request but does not plan to address it, it remains open for discussion labels Apr 9, 2017
@crisbeto crisbeto added the has pr label Jun 4, 2017
@crisbeto crisbeto self-assigned this Jun 4, 2017
crisbeto added a commit to crisbeto/material2 that referenced this issue Jun 4, 2017
* Exposes the dialog config via the `MdDialogRef`. This is shorter than the `dialogRef.containerInstance.config` which was available previously.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Allows for the `disableClose` option to be updated while a dialog is open.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes angular#3938.
crisbeto added a commit to crisbeto/material2 that referenced this issue Jun 4, 2017
* Exposes the dialog config via the `MdDialogRef`. This is shorter than the `dialogRef.containerInstance.config` which was available previously.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Allows for the `disableClose` option to be updated while a dialog is open.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes angular#3938.
crisbeto added a commit to crisbeto/material2 that referenced this issue Jun 5, 2017
* Exposes the disableClose option via the `MdDialogRef` and allows for it to be updated.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes angular#3938.
crisbeto added a commit to crisbeto/material2 that referenced this issue Jun 6, 2017
* Exposes the disableClose option via the `MdDialogRef` and allows for it to be updated.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes angular#3938.
crisbeto added a commit to crisbeto/material2 that referenced this issue Jun 8, 2017
* Exposes the disableClose option via the `MdDialogRef` and allows for it to be updated.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes angular#3938.
andrewseguin pushed a commit that referenced this issue Jun 8, 2017
* Exposes the disableClose option via the `MdDialogRef` and allows for it to be updated.
* Makes the `containerInstance` private to `MdDialogRef` since it doesn't make sense for it to be public anymore.
* Completes the `backdropClick` observable once the associated `overlayRef` is destroyed. This avoids having to unsubscribe manually or having to use `Observable.first`.

Fixes #3938.
@harrymitchinson
Copy link
Author

Nice one, cheers for this :)

@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 5, 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 P5 The team acknowledges the request but does not plan to address it, it remains open for discussion
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants