$modal cant be dismissed if state [ui-router] is changed

[slepkaviba]

Hi,

Using ui-router and $modal brings confustion when $modal inherits scope from current state controller's scope. If state is changed, modal's methods are gone, and its impossible to close it (I tried using $stateChangeStart and $destroy events, but in both - its already too late and dismiss and close have no effect).

One solution was not using inherited scopes but in case they are needed - modal stays open forever.

Br

[chrisirhc]

Could you create a Plunker that demonstrates this?
This sounds like usage with ui-router that's confusing rather than a bug.

[deeg]

Having a simmilar issue, I will try to create a plunkr.

Not sure it has to do with the state change in UI-Router, you should be able to watch for state change start and use $modalStack.dismissAll to close all open modals.

The issue I run into, is $modalStack.dismissAll will not work for all modals, specifically a modal which was passed a scope which is isolated from the rootScope. If I pass the rootScope into the same modal, dismissAll starts to work.

Any ideas?

[slepkaviba]

Sorry for delay. It was exactly same issue. I keep scopes separate and if scope becomes deattached $modalStack cant access methods from it anymore (neither can we).

[rvanbaalen]

@slepkaviba Please answer the question and provide a plunkr. Without a plunkr reproducing the problem, we won't start investigating it.

[deeg]

Creating a plunker wasn't working for me, so it must be another issue than the isolate scope. Still trying to pin it down.

Upon further investigation, I believe it has to do with the $animation service. If I change animation to false everything works fine.

When animation is on and it is not working the following callback is never called correctly:

      domEl.one('$animate:close', function closeFn() {
        $rootScope.$evalAsync(afterAnimating);
      })

[leobudima]

Agreed, came down to same conclusion, $animate:close never fires.

[deeg]

@leobudima, were you able to create a plunker showing the issue? When I tried the issue wasn't happening, which means there might be something else in my code which causes the issue.

[mikesir87]

Ok. I've got more info! It occurs when you specify the scope parameter and that scope is one taken from the current view. Makes sense though... if a ui-state transition occurs, that scope is going to die.

AND.... I made a plunkr :)

http://plnkr.co/edit/OSUSijMgWH5cNvmbSCLG

[moneytree-doug]

👍 Just more information, it doesn't happen in 0.12

[wesleycho]

I believe this is fixed on master: http://plnkr.co/edit/N25cMelap9C718HrVqGS?p=preview

[moneytree-doug]

@wesleycho Why was this with the tag resolution: can't reproduce / no info? @mikesir87 gave a perfect example that reproduces it right there. It is not fixed in the link you provided, and if you open the example and click on "Open with the scope defined" and click "Go" then click the "Close" button, you would notice that it doesn't dismiss.

[wesleycho]

He is using an old version - I linked an updated version without being able to see it reproduced.

[slepkaviba]

@wesleycho on your plunkr bug is the same, I recorded a video with that:

Though - as you reproduced the bug, and provided the example with broken code and latest angular - bug is totally not resolved.

[mikesir87]

@wesleycho - confirmed that bug still exists, even in the plunkr you posted

[wesleycho]

So I think I see what is happening - essentially the $scope that the modal is using is inheriting from the current controller, so when the state change occurs, it is destroyed.

This looks like a bug.

I think an appropriate resolution in the library would be for the modal to close when this happens, as we cannot do anything about this otherwise. On the developer side, I would recommend not using a $scope that inherits from the $scope associated with a particular view that can get destroyed by a $route or $state change. This is because you run the risk of the $scope getting stranded like this. An appropriate workaround is to use $rootScope.$new(true) to create a new isolate scope that points to $rootScope as the parent instead.

[moneytree-doug]

@wesleycho Correct me if I am misunderstanding, but that PR looks like it will dismiss the modal if the route changes. That would be a new unexpected behaviour to me, because it would previously not dismiss if the navigation changes.

[wesleycho]

The problem is, if we don't do that, it causes immense problems, including a completely broken modal due to $scope destruction.

This is the best solution we have.

[liquidpele]

I pulled version 0.14.3 and this fix is not complete because it leaves behind a trasparent div over the whole page... so the modal closes but the page is un-usable going forward.

[wesleycho]

Please open a new issue with reproduction if this is still an issue

[jaybloke]

Experiencing a similar issue. In my particular case my modal attempts to retrieve json data via a resolve on the modal. If I get back a 401 response (unauthorised) via a response interceptor my app automatically presents a login modal - at least that's what it used to do before I moved to the latest version. With the latest version the first modal is never destroyed, and subsequent attempts to open any modal fail. Reverted back to the old version I was using before (0.13.3)... and all works good again.

[wesleycho]

Locking issue due to lack of following of instructions - if there is an issue, open a new issue with reproduction, strongly preferably via Plunker.

Without a reproduction or strong specific evidence, we cannot fix any claimed bug, and the issue queue is not for technical support. Please read CONTRIBUTING.md before distracting people with notifications from commenting on a locked issue.