Inline dynamicContentMacro always has the same width (not resizing properly)

I am trying to implement a simple macro that just displays an inline button. I simply followed the tutorial, changing the the outputType to inline, but the width seems to be always the same:

As you can see, there’s a huge grey area left to the macro, as the width is fixed and it does not resize properly to the width of the macro.

Even worse: When inserting the macro in edit mode, it takes the entire width even though it’s supposed to be inline.

What can I do about it?
It’s defined like this:

  "modules": {
    "dynamicContentMacros": [
        "key": "button",
        "name": {
          "value": "My Button"
        "url": "/button",
        "description": {
          "value": "Inserts a Button"
        "outputType": "INLINE",
        "bodyType": "none"

My template is basically taken from the tutorial, with the layout.hbs looking like this:

<!doctype html>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="ap-local-base-url" content="{{localBaseUrl}}">
  <link rel="stylesheet" href="//" media="all">
  <link rel="stylesheet" href="//" media="all">
  <!--[if IE 9]><link rel="stylesheet" href="//" media="all"><![endif]-->
  <link rel="stylesheet" href="/css/addon.css" type="text/css" />
  <script src="//"></script>
  <script src="//" type="text/javascript"></script>
  <script src="//" type="text/javascript"></script>
  <script src="//"></script>
  <script src="//"></script>
  <script src="" type="text/javascript"></script>
  <section id="content" role="main">
  <script src="/js/addon.js"></script>

And my specific hbs template:

{{!< layout}}
<button>My Button Macro</button>

Hi @PhilipFeldmann,

You can try adding ac-content="ac-content" to your <section/> to that your app iframe is automatically sized.

Alternatively, you can disable the sizing of the macro’s iframe by setting the resize:false option and then call AP.resize(width, height). To set the resize:false option, you can add <div id="ac-iframe-options" data-options="resize:false"></div> to your iframe.


The problem noted by the OP has existed for a while in the Fabric editor, and is really annoying. Actually, it was originally true that inline dynamic content macros could only achieve a max width of 300px, but could be sized smaller if the content allowed it. Sometime in the last year or so it seems that the size of inline dynamic content macros became fixed to 300px, regardless of the sizing needs of the content. These constraints make inline dynamic content macros only marginally useful.

We will do some research here shortly to get a sense of whether or not some of these assertions are still true, but we’ve reached out before on this via both CDAC and DEVHELP to no avail.


Hi @BobBergman,

Thanks for your offer to research this. Please share back any findings, especially any regressions you observe in legacy to fabric editor behaviour. I can ensure issues are created and that the product teams are aware of the problems.



Thanks. We have added a new research task to the top of our queue and will post our findings when available.


Hi @dmorrow

I’ve been investigating this today, and can confirm that the issue occurs as @PhilipFeldmann and Bob have mentioned. Adding the “ac-content” class as mentioned didn’t seem to have any effect.

In both Fabric and legacy, inline dynamic content macros are fixed at exactly 300px, whether the content is:

  • larger than 300px (in which case a scrollbar is displayed) - This has always been the behavior.

  • smaller than 300px (as in Philip’s example) - This is a regression. Previously the iframe would be capped at 300px, but shrink if the content was less than that.

Thanks for taking a look!


And this is in Fabric (could only post a single image as I’m a new user)


I’ve also reproduced this with a very simple app,, and consequently created


1 Like

Thanks @dmorrow

I attempted the AP.resize workaround in that ticket. Even when I set a timer and called AP.resize(200, 20) multiple times it kept getting overwritten back to 300. Below is a gif of what I saw.

EDIT: When I set data-options=“resize: false;” on the all.js script load, it worked fine. That means that the mutation observer is incorrectly calculating the width.

1 Like

Hi @GeorgeSlater,

I think apps should be able to rely on the JavaScript API automatically resizing the macro according to its content by setting the resize option to true (data-options="resize:true") and not calling AP.resize().


1 Like

Unfortunately, as of now you still need to call AP.resize manually and disable the resize option, even though the ticket is labeled as “resolved”.