bug(office): OnlyOffice "file content does not match" on real files (cannot reproduce in playwright) #22

New issue

Open

opened 2026-04-27 16:43:57 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-04-27 16:43:57 +00:00

Member

Symptom

Opening any office file (docx / xlsx / pptx) in headed Chrome (regular or incognito) sometimes shows the OnlyOffice modal:

An error has occurred while opening the file.
The file content does not match the file extension.

The error reappears across container restarts and on freshly-touched files. Browser console shows nothing OnlyOffice-related (only unrelated extension/polkadot warnings).

What we've verified server-side

File on disk has the correct OOXML / pptx / xlsx magic bytes (file confirms Microsoft Excel 2007+, Microsoft PowerPoint 2007+, etc.).
md5sum matches the source seed.
hero_office_server's /files/{ctx}/{name}?inline=1 returns 200 with correct Content-Type and full body (md5 matches disk).
OnlyOffice container's own curl from inside the container against the same URL returns 200 + correct bytes + correct magic.
create_editor_session returns a config with the correct documentType, fileType, key, and url.

What we've ruled out

Browser cache / cookies / localStorage — error reproduces in fresh incognito sessions.
OnlyOffice on-disk cache poisoning — error persists after rm -rf /var/lib/onlyoffice/.../cache/files/data and a container restart.
Stale doc_key — error persists after touch-ing source files (mtime change → new derived key).

Disconnect

Playwright (tests/e2e/office_editor_real.spec.ts) opens the same files in headless chromium and passes 4/4 including pptx/xlsx/docx, against the same hero_os + hero_office stack the user is hitting.
User in headed Chrome incognito fails consistently on the same files.

Plausible suspects (untested)

A browser extension allowed-in-incognito interfering with OnlyOffice resource fetches.
A macOS-level network filter (Little Snitch / VPN / corporate proxy) corrupting binary chunks.
A Chrome-headed-vs-headless behavior in OnlyOffice's sdkjs wasm initialization.

Acceptance

Reproduce reliably on a fresh chromium-based browser without extensions.
Capture an OnlyOffice-side trace (sdkjs console errors at minimum, ideally a HAR of the editor session) showing the actual point of failure.
Either fix the underlying issue or document a workaround (e.g. specific Chrome flag, extension to disable, local override).

## Symptom Opening any office file (docx / xlsx / pptx) in headed Chrome (regular or incognito) sometimes shows the OnlyOffice modal: > An error has occurred while opening the file. > The file content does not match the file extension. The error reappears across container restarts and on freshly-touched files. Browser console shows nothing OnlyOffice-related (only unrelated extension/polkadot warnings). ## What we've verified server-side - File on disk has the correct OOXML / pptx / xlsx magic bytes (`file` confirms `Microsoft Excel 2007+`, `Microsoft PowerPoint 2007+`, etc.). - `md5sum` matches the source seed. - hero_office_server's `/files/{ctx}/{name}?inline=1` returns 200 with correct `Content-Type` and full body (md5 matches disk). - OnlyOffice container's own curl from inside the container against the same URL returns 200 + correct bytes + correct magic. - `create_editor_session` returns a config with the correct `documentType`, `fileType`, `key`, and `url`. ## What we've ruled out - Browser cache / cookies / localStorage — error reproduces in fresh incognito sessions. - OnlyOffice on-disk cache poisoning — error persists after `rm -rf /var/lib/onlyoffice/.../cache/files/data` and a container restart. - Stale doc_key — error persists after `touch`-ing source files (mtime change → new derived key). ## Disconnect - Playwright (`tests/e2e/office_editor_real.spec.ts`) opens the same files in headless chromium and **passes 4/4** including pptx/xlsx/docx, against the same hero_os + hero_office stack the user is hitting. - User in headed Chrome incognito fails consistently on the same files. ## Plausible suspects (untested) - A browser extension allowed-in-incognito interfering with OnlyOffice resource fetches. - A macOS-level network filter (Little Snitch / VPN / corporate proxy) corrupting binary chunks. - A Chrome-headed-vs-headless behavior in OnlyOffice's `sdkjs` wasm initialization. ## Acceptance - Reproduce reliably on a fresh chromium-based browser without extensions. - Capture an OnlyOffice-side trace (sdkjs console errors at minimum, ideally a HAR of the editor session) showing the actual point of failure. - Either fix the underlying issue or document a workaround (e.g. specific Chrome flag, extension to disable, local override).