Forge bridge getContext populates localId incorrectly for connect macros

We are migrating our connect macro to forge. For various reasons, we need to identify the macro in the page content. For that, we retrieve the macro context via forge bridge getContext.

For new style macros (ADF extension style), the localId parameter is populated correctly, however for old ac:structured-macros, the parameter is populated from the (deprecated!) “ac:macro-id” attribute, not the ac:local-id, as we would have expexted. I.e. for this macro

<ac:structured-macro ac:name="graphity-macro" ac:schema-version="1" data-layout="default" ac:local-id="45d9f95a-c98e-48d0-bdaa-ab720089d735" ac:macro-id="a9f0e837-bf15-4317-bcb8-a529ee83861e">...</ac:structured-macro>

the following code

import{ view }from "@forge/bridge"
constcontext =await view.getContext()
const id = context.localId

results in id being a9f0e837-bf15-4317-bcb8-a529ee83861e.

This is pretty unexpected, especially since we have changed all our macro handling code to work with local-id in the past.

Can someone confirm whether this is a bug or intended?

Regards
Jasmine

We encountered this as well. Our app tags macros data by local id in connect and those IDs disappeared “sometimes” after upgrade to Forge. (CustomUI context)

We’ve ended up with some pretty ugly workarounds to map and recover legacy data to the mutated localId after forge upgrade.

Also suggest testing adfExport (e.g. Word) and the new Confluence version history page because we’ve seen they have different localId preservation behavior when compared to the standard live page context.