Getting ReferenceError AP is not defined

I noticed that every day we get a bulk of errors coming from our cloud app. We show a panel on issue view and sometimes AP is not available resulting with ReferenceError: AP is not defined.

So far I know:

  • it happens on old and new issue view experience
  • position of the panel is irrelevant (we show it on the left and right side)
  • majority of problems are on Chrome, some on Firefox

We load host’s all.js first, later our code (we use webpack) all tags located at the end of the body:

<script src="{{hostScriptUrl}}" type="text/javascript"></script>
<script src="{{{furl '/js/vendors.js'}}}" type="text/javascript"></script>
<script type="text/javascript" src="{{{furl '/js/issue-panel.js'}}}"></script>

So AP should already be there.

I found some previous reports of this problem but for Confluence:

Any hints are welcome as I’m not sure how to investigate that further.


If this error is intermittent, the only thing that comes to mind is if an exception occurs during the elaboration of all.js, perhaps due to it processing the query/context parameters passed in the URL? Depending on when/where the exception occurs, it may prevent AP being set.


Thanks, that inspired me to add some code that will save errors from the beginning and report them back to sentry once it’s loaded, will see if that gives more details.

We have the same issue in Confluence! The xdm_e is always set to in this case, which seems odd.

Maybe someone from Atlassian knows where this URL is coming from? The issue started appearing on June 15th. The customer key in the JWT is set to all kinds of different values, the only thing in common is the unusual xdm_e URL.

Probably related to Using AP.request to fetch content from the Confluence host has recently stopped working?

Same issue for us, any known solutions?

1 Like

No solution unfortunately. We live with this error :frowning:


See Please add a CDN mirror for all.js
That thread is a request for Atlassian to provide a CDN fallback/mirror for all.js

1 Like

As Ture said, we are having this same problem on occasion after switching to pulling all.js from CDN. We haven’t figured out for sure if it’s a CDN failure or not, but having a fallback if it is failing to load from the CDN would be valuable, as that’s not an uncommon practice.

Another vendor said that they worked around the problem here by using a custom async wait function that would test for the presence of the AP global in a loop to give it some time to init, and that this approach eliminated the errors for them. Looking at the all-debug.js sources, I don’t see any way that the global couldn’t be there immediately if the script finishes loading without error, though, and we aren’t seeing any other errors being thrown from the AP script itself. I will try this approach, but am skeptical that it will help.

The error rate we are observing is relatively low (maybe 1-20 per day out of 10k+ total requests), but no errors is better than some errors :wink: Most often it occurs on Windows 10 with Chrome, but combinations involving MacOS and Firefox have been observed as well.

We are seeing that some AP related javascript is not loaded. The browser console gives errors like:

> ReferenceError: "_AP is not defined"
>     <anonymous>
> com.atlassian.plugins.atlassian-connect-plugin:iframe-host-utils-v5.js:1:96
>     WRMCB
>     <anonymous>

And many more of these errors. That makes our addon not work properly. Somehow this error seems related to cloudfront failing to load resources.

Edit: this happens in Confluence Cloud

1 Like

Hi @marc,
Are you loading all.js from before you get this error? The reason I ask is because all.js defines the _AP object (you can see the source code at

Yes, I’m loading all.js before. Actually I’m using atlassian-connect-express which does this automatically.
The problem happens intermittently, and sometimes with my customers. I don’t know how often, as the problem is on the client side.


We still observe the problem on our side.

There was another post where other vendors claimed they are affected too. Someone suggested race condition and use of the technique to postpone AP usage until it is defined.

1 Like

@marc and @jack,
There could be different things going on here, but importantly both are issues affecting your customers in production. Could you please raise a bug report in the Developer Service Desk and mention this thread. I’d like to work with you to investigate further

1 Like

Hi @dboyd ,
related thread?

@dboyd, thank you for looking into this.

I’ve raised DEVHELP-4182

1 Like

We are still experiencing this as well when loading from the CDN URL. I’ve posted about it both in this thread and elsewhere, but with no response.

If it possible to add me to the new DEVHELP ticket as well so I can follow along and possibly offer more information? It’s a frustrating problem to know that our users often cannot use our apps because of this, yet we take blame for it.

I would love to have more than one CDN URL available, also, so that when network conditions cause the primary to fail to load, we could fallback to a non-Cloudfront mirror to improve chances of the app loading successfully. Here are other places I have raised this with no response:

related thread?

No, the above incident was not related.

@jack @BobBergman @george1
The _AP loading issue is now tracked at .

1 Like

It looks like that issue is different than the one that the OP and I are talking about. Our issue as raised on the forums is different than this — we simply see that AP is not defined after loading the script from the new CDN URL some small percentage of the time (like 1 in every few hundred). Some customers appear to experience a higher rate of the issue than others. I’ll open a new DEVHELP today.

1 Like