-
Notifications
You must be signed in to change notification settings - Fork 6.7k
bug(modal): nested modal backdrops don't obscure or disable parent modal #922
Comments
Well, I have it working now in my local copy... here's what I did. Would appreciate any feedback to make it contribution worthy:
This works perfectly, even in IE8. I used the style DIV attribute, because I was unsure of how to to be sure how to get at the styles for the div after all classes were applied. If someone could explain how to do that from within the directive, then I could probably just set the z-index on the div directly ( not use the style attribute on the DIV). if that is the best way, I suppose I would need to add code to be sure I am not clobbering some existing style attribute. But for my project I know there is no style on the template so it works in the small. Feedback? |
@jmwolfe thnx for bringing this up. I think that your approach sounds resonable, the only thing I would do is to move more logic to a templates, using the I've proposed something for #892 would be great if you could see if this would work for you. |
@pkozlowski-opensource Thanks for the reply. Not sure I follow how I could move any of this logic to the template. Are you suggesting using We would have to create a whole bunch of classes to support that, it seems. As far as I can see we don't generally add any classes with these AngularUI modules, right? Is there some way to dynamically inject classes? Ah... hm... we could inline a stylesheet into backdrop.html and window.html to support up to 10 layers of popups. But this would make even harder the issue we're working out on #892 I think. So something like the above is better because it lets ngClass take care of duplicate classes (and doesn't require parsing of the existing style attribute? It seems more convoluted and complicated. What big principle am I violating by just enforcing a zindex in the directive on the HTML element? The fix for #892 sounds great, although I assume you're asking regarding THAT issue... it won't fix this issue or provide any better solutions. I guess I can wait until you have your solution in, and then implement one for this issue. I don't think I'll get to it before you can do 892. not to mention I don't have an Angular dev environment set up so that will take me extra time there. Would be cool if there was a virtual image set up for Azure that we could just stand up and start going. :) |
AFAICT this is broken in 1.2 due to the change that properly isolates isolate scopes. The index property is no longer accessible in this ng-style definition:
I'll keep investigating and open an issue. |
Has this been fixed or is there a issue related ? This is closed but I still get this bug. If this has not been fixed I will take a look. |
I believe it is fixed on master, waiting for a release to be cut. We are currently overriding the template to fix this - I'll look it up and post later. |
Here is our template override which makes the backdrops layer correctly on ui-bootstrap 0.10:
|
@chuckd worked just fine. Thanks. |
Hello all! This is my first entry on GitHub, but I've been using angular-ui and angular-bootstrap components for a few months.
I really appreciate the rewrite of the modal and I'm using it on a big enterprise app.
There seems to still be an issue with 'nested' modals. ie a modal opened from another modal. The backdrop from the second modal does not obscure and deactivate the layer modal beneath it. Like the old $dialog, the new backdrop adds opacity to the backdrop but is not z-indexed right to cover the parent dialog/modal.
Admittedly, it's not a true defect at this second, because all dialogs are the same size, so the child modal obscures the parent modal and prevents clicks getting to it. To see this issue, you have to have the css extension fix in place (as noted on Issue #892, custom css class in $modal template) so that the child dialog can be smaller than the parent. Until @pkozlowski-opensource makes his fix in the master, I just used the tweak noted by @richardcrichardc in the issue.
Perhaps its something that can be fixed when the window class extension is fixed, because once you can change the size of the window, you will have these operational issues like Issue #738, modal does not stop tabbing on the background, and of course the problem noted in this issue item.
If we can brainstorm on the best design to fix the issue, I would be happy to try a pull request and to code it.
The text was updated successfully, but these errors were encountered: