-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
Component/s: Forge - App UI Web - Custom UI
-
None
-
Severity 3 - Minor
-
Resiliency
-
M
Issue Summary:
Following the fix released for ECO-1198 (https://jira.atlassian.com/browse/ECO-1198), extension.space now resolves correctly when navigating between Confluence pages. However, the Forge macro extension context continues to supply stale data when the page is edited from a different browser tab. Two distinct context fields are affected:
- extension.content.version — the version of the Confluence page
- extension.macro.body — the content/body of the specific bodied macro instance
Both report the values captured when the extension iframe first bootstrapped, and continue to do so after navigating away from and back to the page. A fresh view.getContext() call does not perform a live read — it resolves the initial-load snapshot. Because two independent context fields, sourced from different context branches, both go stale together and both survive a repeat view.getContext() call, the defect appears to be that the whole extension context is retained from first load rather than a single field's code path being wrong. This is distinct from ECO-1198, which addressed the space-identifier code path only.
Steps to Reproduce
- Create a Confluence page A containing a bodied Forge macro (layout: bodied) that calls view.getContext() and renders extension.content.version and extension.macro.body.
- In the same macro, call GET /wiki/api/v2/pages/{contentId} and render version.number as ground truth.
- Create a second Confluence page B in the same space with an in-app link back to page A.
- Open page A in browser tab 1 and note the reported content.version (and macro.body).
- In a second browser tab, open page A, edit it (including the macro body), and publish. The page version increments.
- Wait 60 seconds.
- Return to tab 1 without reloading it. Navigate to page B via an in-app link, then navigate back to page A via an in-app link.
- Compare the content.version and macro.body reported by the macro context against the live REST version / current body.
Expected Results
The Forge macro context reports the page's current version and current macro body. Following the in-app navigation back to page A, extension.content.version matches the value returned by GET /wiki/api/v2/pages/{contentId}, and extension.macro.body reflects the published macro content.
Actual Results
The context reports the previous version and the previous macro body.
Additional observations:
- extension.macro.body goes stale at the same time as extension.content.version, and both remain stale when view.getContext() is called again (confirmed by a partner reproducing this in production — support ref ECOHELP-155212).
- content.version and macro.body are two different pieces of context data (page version vs macro instance content), yet both are retained from the initial context snapshot. This points to the entire extension context being frozen at first load.
- useProductContext() returned the same stale values as view.getContext() in every capture — switching context API does not help.
- The iframe does remount on in-app navigation — the module-scope bootstrap timestamp changes on each navigation — and the remount is itself served stale content data. This is therefore a data-supply defect, not a lifecycle or remount defect.
- The trigger requires the edit to originate outside the tab holding the macro. Same-tab edits invalidate local state and do not exhibit the issue, which is likely why this has evaded reproduction previously.
Confirmed reproduction configuration (partner, production):
- Native Forge macro (not Connect, did not originate as a Connect app).
- Declared as a bodied macro using layout: bodied per https://developer.atlassian.com/platform/forge/using-rich-text-bodied-macros/.
macro:
- key: smart-tables-table resource: app/tab-tableviewer resolver: function: resolver title: Smart Table layout: bodied adfExport: function: export-tab-macro
- Independently reproduced on a clean bodied macro on an internal dev site for content.version.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available