A day in the life of a Marketplace Partner - Part I

Hi! :wave:

Instead of a rant (ok, maybe it is a bit of a rant) I thought I would give Atlassian an insight in what it means to be a Marketplace Partner and developing apps using Atlassian Connect. I reckon you might not always be fully aware of the challenges we face.

I know you’re not deliberately making our lives miserable, and that there are plenty of priorities to attend, but I figured maybe this will make you more aware of how your decisions and/or inaction impact us as developer. Given the number of small annoyances are… euhm… rather big, perhaps I will turn this into a series :thinking:

Part I: the challenge of sizing the iframe

NOTE: I’m using Jira in the examples, but this applies to all host products that support Atlassian Connect

Ok, so as you already know, the Connect apps run in an iframe. The size of that iframe is of vital importance to an app as this determines the screen estate we can consume.

There are three ways to influence the sizing of the iframe:

It is important to note, that sizeToParent only works on the generalPages module, and not the other modules.

Why is this important? Because sizeToParent is the only way a developer can fully control the screen estate of the app. It allows us to have in-context scroll bars (if necessary) and not have to rely on Atlassian and/or custom solutions to make sure the iframe height matches the height of the elements on the page.

To illustrate the issue, I will share a page I’ve been working on. It is a jiraProjectAdminTabPanels module.

If I do not use the resize data-option or call AP.resize myself, the page will load like this:

To work around this, we have created our own custom resizeFix method, which uses the MutationObserver to detect DOM changes and recalculate the scrollHeight of the root node. If that is enabled, the page loads correctly:

Looks great, right?

We’ve been using that resizeFix for a couple of years now because iframe sizing has been broken for us for almost as long as we’ve been using Atlassian Connect. So why bother writing about this annoyance now, you might ask?

Because I wanted to add resizing animations to my app. If I add the CSS transition, this is what will happen:

screen-capture (18)

As you can see, the transition works, but the iframe is not resized. This is because the MutationObserver is not triggered by the animation. The DOM change occurs before the transition start (change of style attribute), and is not triggered once the transition ends. The transition is a CSS property, not a DOM change.

In order to support this use case, I will need to add an onTransitionEnd event handler which will trigger the resize:

screen-capture (19)

The issue, obviously, is that we have to wait for the entire transition to end before the iframe is resized, meaning that the content will disappear for some time until the transition ends. Not a great user experience.

So how do we deal with this? Because we don’t know the height of the element at any point during the transition. We could add an window.setInterval for every 100ms to recalculate the height:

screen-capture (20)

That… sort of works? On my Apple MacBook Air M2 (2022) at least. Not sure how this is going to work on a crappy desktop found on almost every desk at Evil Corp Enterprise. This is probably not going to be the best UX.

So finally, the only real solution is to just pre-determine the required height and call AP.resize with that hardcoded height prior to running the animation:

screen-capture (21)

Finally, a smooth transition. There are still some edge-cases to attend, but I’m sure we’ll be able to sort them out. It does mean that every time we make content changes, we will need to adjust the hardcoded expected height of the final state after transition. If we forget updating this, we will get a crappy UX.

Now why am I sharing this? Because it took me two days to get this working. The first day I spent on trying to trick Atlassian Connect into allowing me to use a generalPage within the context of the Jira Project Settings decorator (as you can see in the screen grabs there is a atl.jira.proj.config/projectgroup1 location in the sidebar).

That proved to be somewhat hilarious because A) that location is pretty adement on which descriptor module properties are required (spoiler: it does not follow the webItem documentation) or it will not show the link and B) you can actually get a situation in which you have an iframe in an iframe, with a double Jira navigation bar. Unfortunately I forgot to screenshot that and I’m not going to retrace my steps on how I managed to break it, so you will just have to believe me :slight_smile:

The second day was spent on trying to figure out how to get the height transition to work within the context of AP.resize.

Those are two days not spent on creating customer value, but just spent on working around the limitations imposed by Atlassian Connect implementation. I’m pretty sure this is not deliberate. It just not a priority and there are zero fucks given by Atlassian because you never have to deal with it.

I hope somehow this get’s some attention within the DevRel & Atlassian Connect teams. Pinging @dmorrow / @Bentley to see if they can spread the word. Maybe this might actually trigger someone looking into it, but I’m not holding my breath.

BTW, I’m not sure how this works in Forge, but I can image that this has similar challenges with sizing as Forge also runs in an iframe.

NB: the above example is how it works for a Team Managed project. If you use a jiraProjectAdminTabPanels in a Company Managed project, it will behave differently and will look differently (there is no mandatory breadcrumbs in Company Managed, which is in Team Managed). My next post will be about dealing with the inconsitencies between Team Managed and Company Managed :wink:


Totally agree with @remie that iframe size is a big issue. The automatic resizing was terrible, but has gotten a lot better (at least for Confluence macros), which happened sometime last year I think.

1 Like

Thanks for the eloquent write-up Remie. Taking the time to tell the story to this level of detail really helps readers viscerally feel the level of frustration and impact to developer productivity these limitations have (or the impact to UX for app devs who haven’t taken the time to overcome it as you have).

Admittedly, iframe resizing has been one of the more brittle parts of Connect since 1.0. Hopefully one day there will be a better method for sandboxing code in a browser context! But in the interim, I’ve shared this with the Atlassian Connect team for comment. They are slammed with a few different initiatives that introduce new functionality rather than bug fixing or developer productivity currently, so I’m not sure where it’ll sit in terms of priority, but will let you know what I hear back.

iirc Forge does use a slightly different technique for resizing, and you’re correct that apps using Custom UI are also sandboxed with an iframe (though modules using UI Kit are not). I’ll follow up to see whether we’ve explored applying that technique to Connect as well.



I think the easiest fix would be for Atlassian to instead of breaking your head over resizing and sandboxing is to stop trying to control the UX/UI and just let us have generalPages everywhere!


That way we can just control the sizing and scrolling ourselves. You’re already failing miserably in making a uniform UX (exhibit A, B and C), so the argument that this might break user experience is not really applicable.

Exhibit A

Exhibit B

Exhibit C

As you can see here, in Exhibit A, this is a native project settings page, which has the breadcrumbs center aligned. In Exhibit B, you will see the app project settings page in a Team Managed project which has the breadcrumbs left aligned. In Exhibit C you see the same project settings page but in a Company Managed project, which does not have the bread crumbs at all.

If you would have allowed me to use a generalPages module, I would have A) been able to control the sizing & scrolling and B) recreate the breadcrumbs to match the native experience.

I think this would be the easiest & quickest solution. Hopefully the Connect team finds some time to implement this.


It becomes even more fun when you realise that the Atlassian Jira team decided that their initial dog feeding was just not really good enough in terms of UX/UI.

They created an Atlassian Connect app for the Slack integration, which has the same left-aligned bread crumbs:

And decided that this was just bad UX so they actually added a native experience in the Apps menu for the App fields because they probably did not like the UX of the Connect app.

:grimacing: That is a wild array of styles for essentially the same module.

Just to confirm, as an app developer, would you prefer:

(a) Atlassian did render the breadcrumbs, assuming we fixed it to render it consistently
(b) Atlassian does not render the breadcrumbs, and you control the whole experience


I prefer option B. Just give me the whole section

I will recreate the native experience (if applicable) or just create the experience that works best for my app. For instance, we also have a project page which does break the native experience but works best for our app:

As well as a recreation of a native pages (Releases & Components) that follow the same layout but with additional options (specific to our app):

Having the ability to decide ourselves what user experience will in the end allow us to create the best apps for our customers, with the added benefit that we do not have to deal with working around Atlassian imposed limitations.


We’ve also occasionally had an issue with sizeToParent where it would sporadically double the height of a general-page iframe. It won’t affect our content for the most part, but it will inject a huge white space below the content so just looks wrong as a user scrolls down.


Not to mention scrollbars on Windows. Those awesome double twitching one, which resize the view area. My long term favs.

Hi @remie,

Thanks for sharing this extremely comprehensive write-up. I’m glad to hear that you were able to identify a solution to this, although ideally you shouldn’t have had to. I take it from the likes on your post that others have experienced this (or similar) issues before?

You’ve shared that this impacts pages which do not support sizeToParent (i.e. not the generalPages module). Aside from jiraProjectAdminTabPanels and jiraProjectPages, are there other full-page modules which could benefit from similar thinking?

You’re right, we may not be aware of all of the challenges; let’s work towards changing that. Posts like the one you’ve shared raise awareness and help us to understand how and where we may prioritise our effort in the longer term to make Connect a better platform for our development community.

As @tpettersen has shared, we are currently working towards some different initiatives which are adding key functionality, rather than fixing bugs. With that said, understanding which bugs or constraints to developer productivity impact the community the most help us to better balance these priorities in the longer term. I’ve shared a message to book in some time to connect and discuss your experiences further.