Attachments Not Viewable in Office Editor for Confluence

Attachments Not Viewable in Office Editor for Confluence

Problem

If one person on your team can't preview attachments in ikuTeam Office (Excel, Word, PPT, PDF Editor for Confluence), while everyone else, including site admins, can see them just fine, don't worry: this is almost always a network issue on that one person's end, not a problem with permissions or with the app itself.

Application

  • Atlassian Platform: Confluence Cloud

  • App: ikuTeam Office: Excel, Word, PPT, PDF Editor for Confluence

Typical signs:

  • Attachment preview shows a loading error or blank screen for a specific user

  • Error code changes on each attempt (not a consistent error)

  • Site admin can view the same attachments without issue

  • Issue persists after browser restart and laptop reboot

What's actually happening

We looked at the browser logs (HAR file), and the pattern points to a connection timeout (HTTP Status 0) when the browser tries to load this script:

https://editor.ikuteam.com/web-apps/apps/api/documents/api.js

A Status 0 means the browser couldn't reach the server at all, not that it was denied access. In plain terms: this is a network issue on the user's side, not a permissions problem or something wrong with our servers.

What usually causes it:

  1. Stale DNS cache.
    The user's machine or ISP has an outdated address on file for editor.ikuteam.com. A restart doesn't always clear this, and it can take up to 24 hours to refresh on its own.

  2. ISP routing hiccups.
    A temporary break in the path between the user's location and our servers. These tend to resolve on their own once the ISP reroutes traffic.

  3. A browser extension getting in the way. Ad blockers, privacy tools, or security suites sometimes block scripts like this one without meaning to.

  4. Corporate firewall or VPN. Network security rules may be blocking editor.ikuteam.com or ikuteam.com outright.

How to fix it:

Step 1: Check the connection directly

Have the user open this link directly in their browser:

https://editor.ikuteam.com/web-apps/apps/api/documents/api.js

  • If it loads (you'll see JavaScript code): the connection is fine, move on to Step 2.

  • If it doesn't (blank page, timeout, or "connection blocked"): the network is blocking the domain, skip ahead to Step 4.

Step 2: Hard refresh the page

Press Ctrl + F5 (Windows) or Cmd + Shift + R (Mac) to force the browser to reload everything from scratch, bypassing the cache.

Step 3: Test in Incognito or Private mode

Open the Confluence page in a Private/Incognito window. This turns off all extensions and starts a clean session. If it works there, an extension is the likely cause, have the user disable them one at a time to find out which one.

Step 4: Get the domain allowlisted

If Step 1 failed, ask your IT or network team to allowlist:

editor.ikuteam.com

This should be permitted across firewalls, proxy servers, and any content-filtering tools.

Step 5: Flush the local DNS (optional)

If nothing above has worked yet:

  • Windows: ipconfig /flushdns

  • Mac: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

How to confirm it's fixed

Check

You should see

Check

You should see

Open https://editor.ikuteam.com/web-apps/apps/api/documents/api.js directly

The page shows JavaScript code

Open the affected Confluence page

The attachment preview loads with no error

Try Incognito mode

Preview works (confirms it wasn't an extension)

Common questions (FAQ)

Why does the error code change every time?
The error IDs are generated automatically by the editor's error handling. Since the real issue is a connection timeout, the specific code varies from attempt to attempt, that's expected and not a separate problem.

It fixed itself without anyone doing anything. Why?
Most likely the DNS cache refreshed naturally (this can take up to 24 hours), or the ISP resolved a temporary routing issue on its own.

The user restarted their laptop. Why didn't that help?
A restart doesn't always clear the OS-level DNS cache, and it has no effect on DNS or routing issues happening upstream at the ISP.

Could this be a permissions issue?
No, and that's worth knowing upfront: a permissions problem would show a consistent error (like 403 Forbidden) and wouldn't come and go on its own. A Status 0 timeout is a clear sign this is about network connectivity, not access.