A question regarding “state 2”, which includes:
Connect remote iframes must be replaced with Forge Custom UI or UI kit
One of the issues preventing us from moving to Forge (there are many others issues, but let’s focus on this one), is that the sandboxed iframes for CustomUI are more restrictive than Connect, specifically: no
I understand that this was an intentional decision, and that the recommendation for Forge apps that need to open links in new windows/tabs (
<a target="_blank">) is to use the
In our case, this is not easily done. Our Confluence dynamic macro takes user-supplied JSON/YAML (either fetched from an external URL, or embedded into the body of the macro), which may include some arbitrary markdown.
We use a third party library to process this markdown, and by default any links in the user-supplied content are rendered with the
So as the app developer we are neither in control of:
- The user-supplied source that may contain links that explicitly specify
- The library that converts markdown to HTML, which makes all links
We are currently investigating alternate solutions that involve finding all links on the page that have
target="_blank" and augmenting them with an
onclick handler that intercepts the click passes it to
router.open(url). (This may not be achievable in all cases, since some content is dynamically rendered; so some links may not be in the DOM until later).
Will there be any affordance at “state 2” for Connect apps that currently rely on the
sandbox="allow-popup" attribute on remote iframes, or is this something we need to address before we can reach “state 2”?