Issue Summary

When exporting Confluence pages to HTML, anchor links (both same-page and cross-page) do not function as intended. There are two primary failures:

1. Incorrect Link Resolution: Links to pages included in the export are incorrectly resolving to absolute Cloud URLs instead of relative local file links.

1. Broken Anchor Navigation: In instances where the link does resolve to a local file, the anchor reference is ignored, and the browser fails to jump/scroll to the specific section or heading.
   **

Steps to Reproduce

1. Create a Confluence page with several headings and a "Table of Contents" or manual anchor links pointing to those headings.

1. Create a second page with a link pointing to a specific heading on the first page.

1. Perform an HTML export including both pages.

1. Open the exported HTML files locally.

1. Test 1 (Same page): Click an anchor link. Result: It often redirects to the Cloud URL or stays at the top of the local page.

1. Test 2 (Cross page): Click the link from the second page to the first page's heading. Result: The page loads, but does not jump to the section.

Expected Results

• Local Links: If the target page is included in the export, the link must be a local file link.

• Same-page Links: These must always be local file links.

• Navigation: Clicking an anchor link should automatically scroll the browser to the specific heading or anchor point within the exported HTML file.

Actual Results

• No "Jump" to Section: When clicking a local anchor link within the export, the target page opens, but the browser remains at the top of the page instead of navigating to the specific section.

• Forced Cloud Redirection: Same-page anchor links frequently convert to absolute Cloud URLs, forcing users away from their offline documentation and back to the live Confluence site.

• Cross-Page Failure: When Page A and Page B are both exported, a link on Page A pointing to a heading on Page B fails to trigger the scroll action once Page B is loaded.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available