Early Access Program: Forge UI fullscreen modal

Forge Forge UI Kit and Custom UI
,
1

We’re excited to announce the launch of the Early Access Program (EAP) for fullscreen modals in Forge! :tada:

What’s new?

Fullscreen modals are now available for Forge apps, closing a major gap for partners migrating from Connect or building complex workflows on Forge. This new capability allows you to deliver high-density experiences like rich editors and detailed object views, without squeezing content into small modal windows.

Fullscreen Modal Features

  • New fullscreen modal size exists for all Forge UI modals

  • All fullscreen modals exists with an enforced header

    • Developers can nominate icon and name for this header. If none are declared, we will look for any logo or name stored by the app.

  • Improved modal close handling to prevent data loss

    • Close button features a view.onClose method which allows a function to run before the close action is completed. This will support use cases like data saving methods.
      For the EAP this feature is currently opt in. In 2 months, we will elevate to GA which will allow users to click out of all macro custom config modals.

We understand that the enforced header is a new feature from connect fullscreen macros and this may require refactoring from partners. This enforcement was included for accessibility and UX consistency for in-product experiences to ensure we can provide the most seamless experience for end users.

We’re looking forward to your feedback! Sign up for the EAP here.

7 Likes
2

I’m trying to sign up for this EAP as well as the view.onClose bridge method one released today, but both sign-up pages are going to the ‘Forbidden’ page ( Jira Service Management ) instead of the sign-up form. I’ve been able to sign up for EAPs in the past. What am I doing wrong?

3

Hey Quinn!
Are you able to screenshot what you see when you click the EAP sign up link? I’ve been getting requests from other developers.

4

Hey Vicky, sure thing. When I click your link in the post ( Jira Service Management ) it immediately redirects to Jira Service Management . Same happens when I follow the EAP sign-up link posted in https://developer.atlassian.com/platform/forge/ui-kit/components/modal/.

This is the page it redirects to:

Zight 2026-02-03 at 7.03.16 PM
Zight 2026-02-03 at 7.03.16 PM2518×1344 76 KB

5

Hey Vicky,

I’ve been testing the new EAP features and have some quick feedback:

  • view.onClose(): Working perfectly! It’s exactly what we needed to handle saves and cleanup reliably before the modal closes.

  • Fullscreen Modals: The platform-level container enforces a padding with var(--ds-space-300, 24px) on both the header (title/close button area) and the body (left/right sides).

I tested a CSS override in the browser console that reclaimed the space we need. Specifically, adjusting the padding-block-start/end on the header and padding-inline on the body worked much better for our need with --ds-space-100

Since the padding sits outside the Custom UI iframe, we can’t override it. I’ve drafted a formal feature request below to add padding customization to the Modal API to help us fully utilize the fullscreen real estate.

Feature Request: Add style/padding customization options to Custom UI Modal API

Summary

The @forge/bridge Modal API should support customization of container padding (and ideally other style properties) for Custom UI fullscreen modals.

Motivation

When using size: 'fullscreen', the default ~24px padding on the modal dialog container (custom-ui-fullscreen-modal-dialog--header and --body) is excessive for apps that need maximum screen real estate (e.g., embedded editors, dashboards). Since Custom UI runs in an iframe, there is no way to override this padding from the app side.

Proposed Solution

Add optional style properties to the Modal constructor:

constmodal =new Modal({
resource: 'edit-project-modal',
size: 'fullscreen',
// New options:
padding: 'compact', // or a preset like 'none' | 'compact' | 'default'
// OR
containerStyle: {
padding: 'var(--ds-space-100, 8px)',
},
});

Alternatively, expose CSS custom properties that Custom UI apps can set to influence the parent modal container.

Context

The recent v5.12.0 release added icon, title, and onClose support to the Modal API, demonstrating that Atlassian is actively expanding modal customization. Padding control would be a natural addition to these capabilities.

Investigation Notes

  • Root cause: Modal container elements are rendered by the Forge platform outside the Custom UI iframe. Browser cross-origin isolation prevents CSS/JS from within the iframe from affecting them.

  • @forge/bridge v5.12.0: No padding/style configuration options available in the Modal API.

  • No workaround exists from the Custom UI side.

5 Likes
6

Hi @VickyHu,

I see a potential usability issue where users might accidentally click the close button before completing their interaction with the modal. Would you consider adding the ability to define a “Do you really want to discard your changes?” dialog for fullscreen modals?

Although the proposed view.onClose function would allow us to save user input and prevent data loss, treating the close button like a save button seems unintuitive. Do you have any recommendations for how apps should handle this scenario?

1 Like
7

Hey @VickyHu,

We’re hitting a significant design blocker with the current fullscreen modal implementation.

In our use case, the default 24px padding and fixed header structure are causing two main issues:

  1. Visual Fragmentation: Our app uses a specific brand background color. Because the platform-level container enforces a white/black padding area outside our iframe, the app looks “boxed in” rather than truly fullscreen.

  2. Header Limitations: We need to surface more actions/buttons directly in the modal header to maintain a standard editor/dashboard UX. The current container restricts us to just the title and the default close button.

Since we can’t touch the parent DOM from within the Custom UI iframe, we’re stuck with a UI that feels “bolted on.”

8 Likes
8

Hi @VickyHu ,

How can we set the onClose event handler of macro configuration. Without that, changes are lost. Also, it is better to allow a confirmation of closure as suggested above.

Thanks

9

Hi @VickyHu ,

Another issue with the onClose event (I tested it with explicit modal open) is the iframe of the modal is destroyed then the onClose event is triggered. So, there is no way to communicate with the iframe to retrieve the data and save it. Am I wrong?

Thanks

10

Hey Ashraf! Thanks for the feedback!
Hooking into the on.close method will allow a function to run before the iframe closes, so it shouldn’t destroy the iframe before the function runs. If this is the case for you can you help provide a bit more detail on how to replicate this bug?

11

Hey Everyone!
Thanks so much for the valuable feedback.
After review, we’ve decided to remove the padding and reduce the header height for fullscreen modals to provide a less interruptive, more immersive experience. This way you can add your own padding if you require.

As for hooking into the header to insert your own action items. We’re still exploring this and don’t currently have a timeline on delivery here.
Were you able to help provide some examples of how you’d hope this was implemented so we can stress test its impact on the header?

1 Like
12

Hi,

Thank you for the EAP. Unfortunately, it’s yet just another trade-off compared to the “max” size option. As the header cannot be controlled, we’re just wasting 72px of UI. This design and the height is so awkward, that the max option, where the full frame can be controlled, is almost always better, even if you’re looking for a fullscreen scenario.

Proposed solution, either:

  • Remove the header bar entirely and just let vendors do it, like you did with connect, which worked flawlessly and no customer EVER complained about this UX. You’re trying to solve problems that don’t exist in the real world
  • Or at very least, if you don’t trust vendors to properly close the modal, then remove the logo and at least make the X positioned absolute, so that we can use the remaining header space

Thanks,

Philip

2 Likes
13

Hi Vicky, thanks for the update!

I can confirm that the left/right padding has been removed on fullscreen modals, that’s working well on our end.
However, the header height and its padding (24px top padding + 32px header) appear unchanged from before. On our side this is acceptable as-is.

Do you have
a timeline for when the fullscreen modal feature will be GA? We’re currently testing on an EAP instance.