dialog: "Ghost Dialogs" created when $mdDialog resolver fails

[codymikol]

Bug, enhancement request, or proposal:

Bug

CodePen and steps to reproduce the issue:

Ghost Bug Demo which demonstrates the issue:

Detailed Reproduction Steps:

1. In my CodePen open the first Dialog via the "Open This Button"
2. Notice If you press close in the upper right hand corner it will close as expected.
3. Open it again and click on the "BREAKS" button one or more times.
4. Now notice you will have to press the same close button as many times as you pressed BREAKS + 1 in order to close the current dialog.

What is the expected behavior?

When attempting to open a dialog whose resolver object fails to complete, a dialog should either never be created, or treated as cancelled.

What is the current behavior?

A "Ghost Dialog" is created that cannot be seen, butt calling $mdDialog seems to close them. That is why you can press the "BREAKS" button twice and then press close three times before the dialog actually closes. Two "Ghost Dialogs" are created and then cancelled before you can cancel the visible dialog.

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

In our case we utilize large md-dialogs that have a lot of sub-screens in combination with md-tabs. Some of these screens have smaller modals that require network requests that are processed via the resolver. In most cases these are successful and we would not experience this problem, but if a service goes down, the interface would appear to be broken to a user.

Which versions of AngularJS, Material, OS, and browsers are affected?

• AngularJS: Latest
• AngularJS Material: Latest
• OS: OSX / Linux / Windows
• Browsers: Chrome / Safari / Firefox / IE11

Is there anything else we should know? Stack Traces, Screenshots, etc.

It doesn't seem like there are any DOM nodes that get created for these "Ghost Dialogs". Other than that I haven't had much of a chance to look into this.

[codymikol]

Some more information, I've been doing a little digging. It looks like every failed resolve pushed a new dialog into the "showingInterims" Array. So if I can figure out how to ensure InterimElements that fail compilation are not added to this list, that should solve the problem.

[codymikol]

It looks like the issue is coming from this block in the InterimElementFactory

    var showAction = hideAction.then(function() {

      return interimElement
        .show()
        .catch(function(reason) { return reason; })
        .finally(function() {
          showPromises.splice(showPromises.indexOf(showAction), 1);
          showingInterims.push(interimElement);
        });

    });

Two things I notice are...

A: that the catch block is preventing any errors from bubbling up here.

B: We probably should not be adding interim elements that have failed compilation to the showingInterimElements list.

I'm going to work on a PR for this, but this seems to be a pretty core piece of functionality so if anyone knows why this might be intentional I'd appreciate any feedback.

[Splaktar]

Thank you for looking into this. There are certainly some issues with interimElements, but as you noted, they are a very core element for a number of components. I'll try to look at this some more soon.