Problem with nested modals when using Forge module's issue navigator action

[dianaaceves]

Hi!

We are migrating our frontend from Connect app’s issue navigator module to the new Forge jira:issueNavigatorAction module.

Jira issue navigator action

During our migration process from Connect to Forge, we’ve encountered an issue with modal rendering in the Issue navigator. Currently, we must maintain a Connect implementation solely for this feature, as it’s the only way we’ve found to properly render our modal. We’d like to complete our migration to Forge, but the new module is causing problems with modal display.

Specifically, our Atlaskit modal is being rendered inside another modal, creating an undesired nested modal effect.

This is how the modal should render (current Connect module):

This is what happens with the new Forge module:

Configuration options tried:

1. Using actionType: modal (default):

Result: Creates an unwanted nested modal effect - our Atlaskit modal appears inside the Forge modal.

Example: actionType: modal, viewportSize: large

2. Using actionType: dynamic:

We’ve explored both available UI approaches:

1. UI Kit: Not viable as it would require complete application rewrite (we use Atlaskit + HTML + styled components)

2. Custom UI with Bridge Modal API: Creates two separate modals - the Bridge modal and our Atlaskit modal

Example: actionType: modal, Bridge modal size: max

Expected Behavior

We need a solution similar to the previous Connect app behavior, where we get:

• A single modal container

• Ability to render our content directly without nesting

• Control over the modal’s presentation (no external modal affecting our margins/layout)

Question

Is there a way to achieve a single-modal implementation using Forge, similar to how it worked in Connect? Specifically:

1. Can we remove the external modal container?

Any guidance or alternative approaches would be greatly appreciated.

---

Environment:

• App Type: Forge

• Module: Jira issue navigator action

• UI Framework: Atlaskit + styled components

Would be happy to provide any additional information needed.

Thank you so much.

Diana.

[JMwangi]

Holla, btw nice work with being that detailed lol. Now since Forge’s jira:issueNavigatorAction module inherently wraps actions in a modal, it’s causing the unwanted nesting when you try to render your own Atlaskit modal inside it.

To avoid this, instead of using actionType: modal, I’d recommend using actionType: dynamic with Custom UI and controlling the modal entirely within your React code. By using the Forge Bridge Modal API, you can bypass Forge’s built-in modal and directly render your Atlaskit modal at the desired size and style. If you haven’t already, try calling ModalDialog from Atlaskit inside your Custom UI without triggering Forge’s modal.

Alternatively, if UI Kit isn’t an option, you can use Custom UI with the “Fullscreen” viewport and manually position your modal-like UI without relying on Forge’s modal system.

For further details, check these resources:
Forge Modal API
Custom UI Bridge
Jira Issue Navigator Action Module

Hope this is helpful DIana

[dianaaceves]

Hi there!

Thank you so much for your quick response!

I’ll try out your suggestions. While some points aren’t entirely clear to me yet, I’ll review them alongside the code to better understand the implementation.

Thanks again for your help.

[vpetrychuk]

Hi @dianaaceves!

I’d suggest going with a actionType: dynamic UI Kit component where possible because it allows registering custom modal controls that are properly positioned, which results in the best UX. If that’s not possible e.g. because of the (temporary) missing features in UI Kit, I have created an example app snipped and recoded a video explaining how to render Custom UI inside the UI Kit Modal (sorry for the quality, I had to download it and re-upload again):

How to render Custom UI inside the UI Kit Modal

The app itself won’t be working out of the box when you run forge register, because it misses a few files, but the code is working fine and you may just copy/paste it into your app.

What it does/can do:

1. Defines a resource that conditionally renders the modal contents based on the context, so when it is used by the global/project of any other module, it can be rendered as a regular Atlaskit modal, but if it is rendered by the issue navigator action one, only its contents is rendered.
2. Renders the mentioned above resource inside the Modal body utilizing the Frame component.
3. Communicates to the Custom UI from UI Kit to perform the action on action button click.
4. Automatically resizes the modal height based on the Frame height.
5. Can programmatically change modal size, see docs.

A few screenshots showcasing how it looks:

Hope this helps!

Thanks,
Vitalii

[dianaaceves]

Hi @vpetrychuk!

Thank you so much for taking the time to provide such a detailed explanation, complete with video and screenshots. This is incredibly helpful.

I’ll implement your suggestion and let you know how it works out.

Really appreciate your support!

Best regards,
Diana.

[dianaaceves]

Hi, Vitalii!

Over the past few days, we’ve been testing and experimenting with the code example you provided, trying different approaches to adapt it to our needs.

Your suggested solution would be perfect for a standard modal implementation - and I apologize for not previously mentioning the complexity of our specific case, which you couldn’t have known about.

Unfortunately, this approach won’t work for our use case. The suggested solution proposes using a Forge modal as a container and injecting our content into its body. However, our modal implementation is significantly more complex, with multiple dynamic paths that render different headers, bodies, and footers depending on where the user is in the export process or form flow.

We attempted to use the Forge modal as a parent container while maintaining our Atlaskit Modal components (ModalHeader, ModalBody, ModalFooter) inside it . However, this isn’t feasible as these Atlaskit components require their parent Modal component to function properly. When we include the Atlaskit Modal, we end up with two nested modals again (Forge and Atlaskit).

Migrating our entire modal codebase from Atlaskit to Forge UI Kit would require a substantial refactor of a critical part of our application. Given that we’ve just launched to production, undertaking such a significant restructuring isn’t viable at this time.

Is there perhaps another approach that would allow us to maintain our existing Atlaskit modal implementation while still migrating to Forge?

Best regards.

Diana.

(I attach some screenshots of some parts of our code so you can see what I mean.)

[vpetrychuk]

Hi @dianaaceves,

Unfortunately this is the only way at the moment, it won’t be possible to have Atlaskit modal “as is” rendered without any additional work, I’m sorry for that. However, I’ve got another idea and will get in tough with the team, perhaps we could figure something out. I’ll provide an update when I have one.

Thanks,
Vitalii

[dianaaceves]

Thank you very much, I will keep an eye on it.

Have a nice day!

Diana,

[vpetrychuk]

Hi @dianaaceves,

Just confirmed with the team that another idea I had won’t work. At this point the initially suggested way to resolve it by placing only modal body to Frame component and implement both footer and header on the UI kit side using the event system for communication is the best way to solve your use case.

I’d also suggest to raise a public ticket describing your problem in a more general way so other developers could vote for it.

Thanks,
Vitalii