How to close all modals

hi guys, i want close all modals behind the top modal with dismiss.
how i can do

You have to keep the instance references to each modal so that you can programmatically reference them to call the close method.

What about a nice service? A method, who opens the modals and registers their instances in an array property of that service. All modals handled on a singleton like class. A second method to dismiss all instances in that array.

With best regards

can you expand how one would do that?
does one give each modal constant a unique name?
eg in parent.ts
async openPrintModal() {
const printModal = await this.modalController.create({
component: ResultsPrintModal
await printModal.present();
then call dismiss on that constant?
eg printModal.dismiss({});
but if you are calling that dismiss from another modal, does that mean you have to import & inject every modal you wish to dismiss into the dismissing modal?

I think the entire premise of this thread is flawed, because there should never be a situation where more than one modal exists.

should yes, but if you’ve spent any time programming in the real world you should already know thats often not how it works out.

In my case business rules -> client prefs -> design. I don’t have any choice in the matter. One feature modal can spawn either a confirmation modal, or cancel model either of the latter should close the former.

while i agree with you regarding best practice, questioning the premiss does’t help answer the question, or educate anyone

Almost 40 years, if you want to play that game.

I could not disagree more. I think it is in fact a more important aspect of programming to learn what not to do and why not to do it than it is how to do things, and hope that my comment encourages somebody (if not you) to push back intelligently against:

I think it is an important part of being a professional programmer to be able to explain concepts to clients or management in such a way so that they accommodate your expertise into their thinking. I can’t see any self-respecting surgeon agreeing to perform an operation with a chainsaw simply because the patient insisted on it.

Additionally, there’s a future-proofing aspect to this. I would not be surprised if a framework decided to make this impossible in the future, even if it wasn’t now, say for example by enforcing an app-wide singleton modal. It doesn’t rise to the level of classics like a[i] = i++, but a service that tracks multiple overlays skates too close to the abyss of undefined behavior for my comfort.

I’ve said my piece. You may have the last word if you wish.


sir, i came here looking for help, not judgement. Definitely not a fight.
(i continue in frustration but good faith…)

I didn’t say you don’t have experience, I said if you had experience this shouldn’t surprise you, which frankly I stand by.

Cool. You have two decades more experience than I do …so maybe you can help?

If I were to be in a position to answer this question, and in cases where i have been able to answer similar questions, I would be inclined say something like
“I think this not the best way to go about things, because x, y & z, but if you need to, here are some pointers.
or if you have more time"here is are some pointers for what you are trying to do… but here is a better way, and this is why”

I’ll add that ime when someone is ramping up on a new tech or framework, even talking through bad design patterns can be a teaching opportunity

I’m pretty frustrated feeing like i have to justify myself, but i did not design or build this. It’s revamping a product that is already in market, with existing users used to the existing functionality. but most importantly a contract has been signed agreeing to the finished designs. I was not consulted in the planing phase, I’ve been brought in to finish it. I am working on a very tight deadline. I need to finish this. If I get it done this time, maybe next time I’ll have more input.

Again i agree with your take on good design, and future proofing
but again the real world is messy & imperfect.

In this case I have no say, and again I didn’t post do the forum, “Do you think this is a good idea?” I asked how to go about what was suggested.


If anyone comes along looking for an answer, at least to my specific conundrum:
A Modal, calling B modal…and wanting to cancel on B modal to close both…
I found a solution, i’m sure it’s not as elegant as it could be but it works - and I love to hear constructive criticism

I made an async function inception ;> in the A/Parent modal that take an argument to tigger the close function

async inception(bluePill, redPill){
if(bluePill == true){
await this.modalController.dismiss();

then chained an .onDidDismiss() function the B/child modal’s instantiation function that passes trigger value from B modal via to the inception function.

async openCancelModal() {
const modal = await this.modalController.create({
await modal.present();
.then( result => this.inception(,;

1 Like

In the component of the first modal, put this code, when the second one closes it will close the first one too.

 const modal = await this.modalController.create({
      component: SecondModal
    return await modal.present();

        () => this.modalController.dismiss()

I tried with this method, but it still not working, even I make async in the Promise method.
Something like this:

modal.onDidDismiss().then(async ()=> {
await this.modalCtrl.dismiss();

Where or how do you use the "onDidDismiss()?
Because in my interpretation, yo use it in another method, can you show me more details, pls


// My solution is to prevent multiple instances of the same modal to pop

this.modalCtrl.getTop().then((res) => {
if (res) {
console.log(“Another modal is up”)
else {
this.modalCtrl.create({ component: LockedPage, cssClass: ‘lock-modal’ }).then(i => i.present())

Thanks and I agree with you totally!