Material: dialog(multiple): backdrop problem with multiple dialogs

[KZRepository]

Bug, enhancement request, or proposal: BUG

CodePen and steps to reproduce the issue:

CodePen Demo which demonstrates the issue:

See the Pen 858d4284dd32a420f45d2a4cc0f4ff62 by David (@StretchKids) on CodePen.

Detailed Reproduction Steps:

1. Open the first dialog
2. Then open the second dialog

What is the expected behavior?

In a nutshell, the dialog has a backdrop (a transparent white background layer) that is one z-index below the dialog.

The first dialog opens with a z-index of 50 and a backdrop of 49. The second dialog on top of it opens with a z-index of 80 and a backdrop of 79.

What is the current behavior?

The problem is that then changes the first dialog to a z-index of 80 and a backdrop of 79. In effect, no backdrop for the second dialog.

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

Showing one dialog on top of another. The top dialog is lost on the bottom without the backdrop.

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

• AngularJS: 1.7.4
• AngularJS Material: 1.1.10
• OS: Windows 10
• Browsers: Chrome Version 69.0.3497.100 (Official Build) (64-bit)
  Firefox: 62.0.2 (64-bit)

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

The md-dialog tag has an ID. The .md-dialog-container and the md-backdrop do not.

[codymikol]

Hello, You can get the behavior you'd like by specifying the parent on your dialog. Working example here

I like to use

parent: document.getElementsByClassName('md-dialog-container')[0]

Works well on double nested dialogs, not sure about triple nested.

[KZRepository]

Hello, You can get the behavior you'd like by specifying the parent on your dialog. Working example here

I like to use

parent: document.getElementsByClassName('md-dialog-container')[0]

Works well on double nested dialogs, not sure about triple nested.

Thanks! That works.

The result is a bit bizarre internally. The md-backdrop and md-dialog-container of the second dialog are under the md-dialog-container of the first dialog. The z-indexes are still changed erroneously. both backdrops are at 79, both containers at 80.

Another workaround I was considering was at the onCompleted event cycling through the md-backdrops and md-dialog-containers and set their z-indexes starting at 49 and 50 and incrementing each by 30. It just seemed a bit of a hack. The equivalent of replacing a fork a guest dropped on the floor.

This need for using parent doesn't seem to be documented. I wonder if it was what 'parent' was created for. The designers seem to have intended incrementing z-index to solve this...but have something broken in the code that changes all the md-dialog-containers and all the md-backdrops, not just the new dialog.

[Splaktar]

I believe that this is related to https://github.com/angular/material/issues/11308 as well.

[KZRepository]

The parent fix seemed to have a problem. It caused the system to be unable to open subsequent dialogs. I haven't had the time to debug. This didn't occur in the Codepen but does in the app. I haven't found what is causing it. There doesn't appear to be any HTML left behind.

I created a short function to reset the z-index in the onComplete function. It does reset them, then a fraction of a second later. Put in a $timeout with 1/2 second delay, it reset it...and then the system reset it again.

This is the function I used:

       function changezindex(){
            let base = 50;
            let increment = 30;
            for(i=0; i,5; i++){
                let container = angular.element(".md-dialog-container", i);
                if(!container.length) break;
                let backdrop = angular.element("md-backdrop",i);
                container.css("z-index",base+increment * i);
                backdrop.css("z-index",base+increment * i -1);
            }

[codymikol]

@KZRepository did you ever have time to debug this issue?

[Splaktar]

Can you please test this again now that PR https://github.com/angular/material/pull/11472 got merged and released in 1.1.14?

[Splaktar]

No response to the request to test this in a release after 1.1.14. Assuming this is resolved in recent releases.