Add support for hiding a dialog without closing it

Bug, feature request, or proposal:

Only show one dialog at a time.

What is the expected behavior?

When a dialog is opened from within another dialog, all other open dialogs should be hidden.

What is the current behavior?

The new dialog gets layered on top of the old dialog(s)

What are the steps to reproduce?

1. Open a dialog
2. Open another dialog from within that dialog

Plunker: https://plnkr.co/edit/GglOLDnx1uJlZRgD4y1W?p=preview

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

In angularjs material, multiple dialogs weren’t allowed by default. See, for example http://plnkr.co/edit/qNu3q5XsIie1fYjKeJRc?p=preview. Ideally, though, there’d be a virtual stack of dialogs maintained, where only the topmost item on the stack is visible.

Is there anything else we should know?

Currently, I can work around the issue by running

Array.from(document.querySelectorAll(".cdk-overlay-container .cdk-global-overlay-wrapper")) .forEach((node, index, array) => (index !== array.length - 1) ? (<HTMLElement> node).style.display = "none" : true);

in ngOnInit, and running

Array.from(document.querySelectorAll(".cdk-overlay-container .cdk-global-overlay-wrapper")) .forEach((node) =>(<HTMLElement> node).style.display = "" );

in ngOnDestroy.

This works, and effectively creates a stack of hidden dialogs. But I don’t want to add that snippet in every dialog that could possibly be opened from another dialog.

[julianobrasil]

If the default behavior is to hide the dialog, maybe the hide API isn’t so confusing. An attribute in the parameter object passed to the open function would be simple to use. It would be something like

dialog.open({
  hideOnCascade: false 
});

The default behavior would be true. So the user could specify different when necessary.

[superMDguy]

The PR @willshowell’s mentioned is a step in the right direction. Additionally, it’d be good to either have a way to add a class to a MdDialogRef, like @jelbourn suggested, or to have an automatically applied “inactive” class, like I suggested earlier. I like the “inactive” class better, because it makes things cleaner for me, but if it’s too much of a niche use case it might be better to just use @jelbourn’s suggestion.