Issues loading Confluence macros within a dynamic macro

Currently we have several dynamic macros that allow the “rich-text” body type but we’re having difficulty getting Confluence macros placed within ours to work correctly. I’m keen to know if anyone else has had any related issues and if you’ve found any solutions to the problem.

Context

When a Confluence page is loaded, on the server side we:

  1. Request the macro’s body
  2. Use “/rest/api/contentbody/convert/view” with the required expand parameters set to produce the HTML for the content of the macro and the needed JS/CSS resources (webresource.superbatch.metatags, webresource.superbatch.tags.all, webresource.tags.all).
  3. Insert this in the correct order into the HTML response from the server and thus is then loaded into our macro’s iframe within the Confluence page.

The issue

Some macros work, some don’t. In particular the “JIRA Issue/Filter” macro is throwing errors when it attempts to load.

Based on the error below is appears to be related to the REST interface to WRM (web resource manager?) and is clearly caused by CORS attempting to lazy load web resources required by the JIRA Issue/Filter (this JS code will obviously be running in the context of our domain within the iframe).

Error details

OPTIONS https://xyz.atlassian.net/wiki/rest/webResources/1.0/resources 415
    send @ jquery-1.7.2-confluence-v5.js:20
    ajax @ jquery-1.7.2-confluence-v5.js:20
    _getScriptsForResources @ batch.js?locale=en-GB:124
    _resolveAsync @ batch.js?locale=en-GB:124
    l @ batch.js?locale=en-GB:124
    require @ batch.js?locale=en-GB:124
    WRM.require @ batch.js?locale=en-GB:129
    (anonymous) @ confluence.extra.jira:jira-issues-view-mode-resources.js?locale=en-GB:5
    k @ batch.js?locale=en-GB:1076

XMLHttpRequest cannot load https://xyz.atlassian.net/wiki/rest/webResources/1.0/resources. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://abcdefg.au.ngrok.io' is therefore not allowed access. The response had HTTP status code 415.

Related links

https://ecosystem.atlassian.net/browse/CE-968

Also see https://ecosystem.atlassian.net/browse/CE-919. Looks like the fix is rolling out fairly soon. We’ve encountered a number of macro-in-a-macro issues and have been either working around the issues ourselves or reporting them. Many of our work-arounds has been in fixing up urls that are relative and end up calling back to our add-on instead of the instance.

Thanks Jeff, current waiting for that to be live.

Regarding relative URL’s have you tried a <base> tag? That seemed to solve all of our relative URL issues so far (maybe we haven’t tried hard enough to find more macros with issues)

Thanks Tim. Yes we tried <base>. Doing so does require us to make all URLs absolute that we need to load from our add-on. Somewhat of a pain. It just feels like since the Confluence content is being generated by the instance and called from a Connect add-on that we shouldn’t have to jump through hoops to make that content work. There’s also some concern with how well is supported in things like JQuery. Maybe those concerns are based (no pun intended!) on old history. We’ve seen the relative url issues with src, srcset, and url attributes on the different tags (e.g. tags when not using the default image size). Hopefully once we see the fix for this issue here that similar changes will be rippled throughout the other Confluence macros.