Modal dialogs as a standalone module

Are there any plans to offer a proper “Modal Dialog” module (with custom UI support) in Forge? In Connect it was possible to register a dialog as a standalone module and then open this dialog from any other screen. That had the advantage that it didn’t matter where the dialog was opened from, the dialog always covered the whole screen (with the dialog blanket or the dialog itself).

Currently any modal dialog opened from a custom UI will not be able to do that, because the custom UI is limited to the bounds of the iframe that it is in.

Use cases for this that we have found so far:

  • A custom UI in a confluence:spacePage that opens an Atlaskit ModalDialog will work but will be very ugly because the dialog blanket will not extend outside of the iframe given, so the Confluence navigation, header, etc… will not be covered by it.
  • Opening a modal dialog via a button in a confluence:contentBylineItem is only possible via UIkit for the same reasons because a custom UI dialog would always open “inside” the inline dialog provided by the byline item.
  • Mixing UIs written in UIkit and UIs using custom UI is not really possible. Sometimes it would be easier to write a single dialog in UIkit and open it from a custom UI page or the other way around.

I guess this would require two things to be implemented: being able to define a modal dialog as a module and then a way to call this module from another module (custom or UIkit).

1 Like

Hey @thomas2,

Thanks for the feedback! Opening dynamic modals in custom UI is something we are looking at but still working on prioritising. To help us prioritise this against other custom UI features, do you feel this limitation is a blocker for your app? For example could you work around this through a SPA spacePage that doesn’t use a modal or through using a larger viewportSize with contentBylineItem?

1 Like

Hey, good to know that you are already looking at it.

For us it’s not really a hard/technical blocker, we have already worked around most of these issues. I think it’s more about the end-user experience, since the workarounds we used (or the ones you mentioned) are not always very user friendly. Or the workaround might mean that the UI behaves a little different compared to how Confluence/Jira apps would typically behave.

I understand that things like that are probably not the first priority for Forge development right now since there are workarounds. But since Forge apps can be released to the marketplace now/soon it would also be nice to also get some focus on things like that that make the end user experience a bit nicer. :slightly_smiling_face: