Issue Summary:

When Jira's frontend loads a Forge app, it issues a single GET for the app's iframe document from the Forge CDN sandbox host (*.cdn.prod.atlassian-dev.net). If that request fails at the network layer (HTTP status 0, for example net::ERR_SOCKET_NOT_CONNECTED), Jira does not retry the request and does not render any error or recovery UI. The user is left on Jira's loading skeleton (pulsing grey bars) permanently, with no indication of failure and no way to recover short of a full page reload.

The iframe element and its document request are created by Jira's own frontend bundle, and this request is the app's entry point, so the failure occurs before any app code is fetched or executed. As a result it is not detectable or recoverable by the app vendor. The vendor has no hook to observe, report, or retry it.

The underlying network error is transient and retryable. It originates in the browser (Chromium reusing a dead socket from its idle keep-alive pool), so a second attempt on a fresh socket succeeds. A single automatic retry would make the failure invisible to the user.

Environment

• Product: Jira Cloud
• App type: Forge app rendered in an iframe
• Browser: Chromium-based browser (reproduced on Microsoft Edge 153, Windows 10 x64) with speculative preconnect enabled

Steps to Reproduce

1. Open a Forge app in Jira in a Chromium-based browser (Edge/Chrome) where speculative preconnect ("Preload pages for faster browsing and searching") is enabled.
2. When the browser reuses a stale/dead pooled socket for the iframe document request to the Forge CDN sandbox host, the request fails with status 0 / net::ERR_SOCKET_NOT_CONNECTED before contacting the server.

The trigger is transient and not fully deterministic, but has been observed reliably in the field. In a captured example it occurred on a normal page load roughly 9 seconds into loading.

Expected Results

• On a network-layer failure (status 0 / net::ERR_*) of the Forge iframe document, Jira retries the request at least once on a fresh connection.
• If the request still fails after retry, Jira replaces the indefinite loading skeleton with an error state and a retry control, instead of leaving the skeleton displayed forever.

Actual Results

The iframe document request is issued exactly once. On failure it is never retried, no error state is shown, and the app remains on the loading skeleton indefinitely. The only user-side recovery is a full page reload (clearing the browser cache also works, but only for one subsequent load).

Evidence from a HAR capture (one page load, 186 requests):

• The failing request is the Forge app's iframe document, served from the Forge CDN sandbox host (*.cdn.prod.atlassian-dev.net):
  • status: 0
  • error: net::ERR_SOCKET_NOT_CONNECTED
  • resourceType: document (the only document-type request besides the top-level Jira page)
  • serverIPAddress: empty, no connection assigned, bodySize -1, no response headers
  • timings: blocked ~500 ms; dns -1; connect -1; ssl -1; send 0; wait 0; receive 0 (no server contacted; socket taken from the idle pool and found dead on write)
  • initiator: Jira's own frontend bundle (jira-fe...public.atl-paas.net)
• The request is issued at approximately t+9s. The recording continues to approximately t+26s. Across the requests that follow the failure (Jira frontend scripts, product API/XHR calls, static assets, and analytics beacons), the failed iframe URL is never requested again.
• This iframe document is the only request in the capture that fails to reach the server. Two other requests show a benign net::ERR_ABORTED (a logging POST that returned 204 and a product fetch that returned 200), consistent with normal page-navigation cleanup and unrelated to the app failure.
• The iframe request carries platform feature flags including forge-ui-iframe-analytics and forge-ui-iframe-ufo-perf-observers, indicating the platform instruments iframe load performance, but no retry or recovery action is taken on the status 0 failure.

Workaround

The only known workaround is browser-side: disabling the browser's speculative preconnect setting (in Edge: Settings > System and performance > "Preload pages for faster browsing and searching") prevents the preconnect that produces the dead socket. This degrades general browsing and is frequently blocked by corporate device policy, so it is not a viable fix for most users. Clearing the browser cache also works, but only for one subsequent load.

Impact

This symptom is reported regularly, typically described as "the app won't load / blank screen with pulsing bars". Diagnosis currently requires collecting a HAR from the affected user. Because the failure occurs before any app code runs, vendors cannot detect or mitigate it. A single automatic retry on the iframe document request would make the failure invisible to end users.