Automatic resizing when using Modal-Dialogs

I tested the new feature for custom-ui apps in conjunction with Modal dialogs - and observed a strange behaviour in the Modal Dialog. But step-by-step.

So looks my simple Custom-UI app:

First I used a div-wrapper to the Modal-Dialog without any height css-parameter. So I received the following output when I activated the Modal-Dialog via the button:

As you see the dialog shrinked.

So I used a certain height css-parameter: 300px; for the div-wrapper.
Wow - I got the result I wanted:

… BUT when I move around with the mouse => the height of the background grey area increases ceaselessly:

Does anyone has any idea which css defininition I should use - or is this a bug of the new “automatic resize” function?


@PeterYu, did you observe such a behaviour as well?


Hey @FranzBinder, thanks for raising this.

Would you be able to share what module your Forge app is using? e.g. is it a macro or confluence:spacePage etc.?

Could you also share some of the code that you are using to define and open the modal?

1 Like

Hey @kchan ,
sorry I forgot to mention that this is a Confluence macro.

Pls see below the major code parts.

Thanks & BR,


const Frame = styled.div`
  background-color: lightyellow;

const App = () => {
  const [isOpenModal, setIsOpenModal] = useState(false);
  return (
      <p>This is a dummy text</p>
        onClick={(e) => {  setIsOpenModal(true);  }} >
        Go to Modal-Dialog </Button>
      {isOpenModal && <MyModal setIsOpenModal={setIsOpenModal} />}


const FrameModal = styled.div`
  height: 300px;

const MyModal = ({ setIsOpenModal }) => {
  const closeModal = () => {  setIsOpenModal(false); };

  return (
          <ModalDialog onClose={closeModal} heading="Test Dialog">
              onSubmit={(formState) => {  setIsOpenModal(false);  }}    >
              {({ formProps }) => (
                <form {...formProps}>
                  <Field label="Field 1" name="field1">
                    {({ fieldProps }) => <TextArea {...fieldProps} />}
                  <Field label="Field 2" name="field2">
                    {({ fieldProps }) => <TextArea {...fieldProps} />}
                    <Button onClick={closeModal}>Cancel</Button>
                    <Button type="submit" appearance="primary">OK </Button>

Thanks for that @FranzBinder. We don’t really recommend using Atlaskit modals in Custom UI because they don’t really work very well in the context of an iframe generally.

Instead, we’ve implemented a more native/fully integrated experience for Custom UI modals:

However, we are still in the process of enabling these to be used in the Confluence macro module. I can let you know when that work is finished.

That said, the continuous size increase does seem to be undesired behaviour nonetheless. I’ll have a go at reproducing your issue, in the meantime, to see if there is a reasonable workaround.

You should be able to disable automatic resizing by adding a viewportSize property to your manifest for that module. If you already have defined a viewportSize for the module, then the issue is not related to automatic resizing.


Thanks for the explanation @kchan !!

I read the description for Custom-ui-bridge/modal but I’m a little bit confused how to use it. Do you have any real live example / instruction?
Additionaly I don’t understand the need to use the bridge for a modal dialog which is used on the Custom-UI / React side. The Atlaskit approach seems more logical for me :confused:

One more question: are there other Atlaskit elements which you don’t suggest?

Regarding viewportSize : I tested different sizes but I love the ability to show the whole content without scrollbars. Disabling automatic resizing is in this case not a good alternative.


@FranzBinder great question, I don’t know of any live code examples, but I can try explain usage in a bit more detail.

In your Custom UI app (not the modal), you will need to first instantiate the modal:

import { Modal } from '@forge/bridge';

const modal = new Modal({
  resource: 'my-modal-resource',
  onClose: (payload) => {
    console.log('onClose called with', payload);
  size: 'medium',
  context: {
    customKey: 'custom-value',

Then you can add to the event handler for the button that opens the modal.

The modal itself must be defined as a Custom UI resource itself. You can either define a whole separate resource for it (the resource in the constructor of Modal refers to the resource’s key in the manifest), or you can use the context above to tell the Custom UI code to render a modal. E.g. you might pass in { isModal: true } to the context, and in the resource, you can use view.getContext() to render the modal UI or the app UI based on isModal.

In the modal UI, you can use view.close() to close the modal, and if you want, to send data back to your app to do something with it (defined in the onClose handler above).

import { view } from '@forge/bridge';

const context = await view.getContext();
const customValue = context.modal.customKey;

  formValues: [],
1 Like

Yeah, if the Atlaskit modal could work, that would definitely be the most sensible option. Unfortunately, features like modals and any kind of pop-up or drop-down don’t work very well with iframes. That’s why we’ve created this separate Custom UI modal feature, as a way to create a modal experience within the constraint of iframes.

Re: not wanting to use viewportSize. Understood, we are working towards making Custom UI modals available in macro. In the meantime, is it possible to workaround using a different UI experience (e.g. changing what is displayed in the app directly to show what was going to be in the modal)?

1 Like

We’re seeing this as well in Jira’s project page module. Since forge modals aren’t an option for us - can we get a proper fix in for this?

Forge not supporting atlaskit is kinda surprising to me.

@danielwester can you elaborate on why Forge modals are not an option for you?

There are many reasons. The biggest one is that I’m using drop downs which does not work with connect or forge iframes (try positioning an atlaskit/select at the bottom of the frame with 10 options).

The safest approach for me is to get as big of a rendering area and for me to handle the rendering.

This is a bug in forge - which is going to make me have support costs.

@danielwester thanks for describing that. I can understand why that’s problematic.

I’ve tracked this feedback here: I also left a comment on a potential solution, although it’s just me thinking out loud.