[Rikdekker]

• Resolves: Federated document: closing the editor leaves a blank page since 10.3.0 #6094
• Target version: main

Summary

A federated file is edited through /apps/richdocuments/remote on the instance that owns it, embedded in an iframe on the instance the user is on (the initiator). Since #5874, document.js sends every message for the parent window to window.location.origin. On the remote page that is the owner's origin, not the parent's, so the browser drops all of them:

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://owner.example') does not match the recipient window's origin ('https://initiator.example').

Closing the document never reaches the initiator. The owner hides its editor, the viewer on the initiator stays open over the empty owner page, and the URL keeps openfile=true&editing=false. Escape or a reload gets out of it.

This passes the initiator's origin to the page as parentOrigin, and document.js uses it as the target origin for parent and accepts messages from it. The value comes from the server, not the query string: remote() only renders after getRemoteFileDetails() has checked that remoteServer is a trusted server and confirmed the token with it. Pages that are not opened through remote() get no parentOrigin and keep using their own origin.

The fix proposed in #6094 reads remoteServer from the query string with getSearchParam(). That helper decodes with decodeURI(), which leaves %3A and %2F encoded. new URL() then throws, and the code falls back to the page's own origin, so the bug stays.

The second commit drops _.bind() from the remote page. Server 36 no longer provides the underscore global, so on main the remote page threw _ is not defined before the editor loaded. Without the binding the handler is the same, since onClose only refers to documentsMain. Server 33 still has the global, so on stable33 this commit changes nothing.

How I tested

One dev container (npm run dev:server) acting as two instances through two origins: the owner on http://127.0.0.1:8081, the recipient on http://localhost:8081, with a federated share between them and both origins as trusted servers. Collabora needs --o:net.frame_ancestors=127.0.0.1:* for this. A Playwright script opens the shared document as the recipient, clicks Collabora's close button and checks the viewer.

	stable33 (10.3.2)	with this fix
Viewer closes after "Close document"	no	yes
URL after closing	…?dir=/&editing=false&openfile=true	…?dir=/
postMessage origin errors in the console	yes	none

Done on stable33 (server 33.0.10 RC1, 10.3.2 without and with the first commit) and on main (server master, both commits). On both, a local, non-federated document still opens and closes. DocumentControllerTest passes on both, and the new test fails without the change to the controller.

The Cypress test for federated documents (share-federated.spec.js) is skipped, and it runs on a single origin, so it could not have caught this.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Documentation (manuals or wiki) has been updated or is not required

/backport to stable35 please
/backport to stable34 please
/backport to stable33 please
/backport to stable32 please
/backport to stable31 please
/backport to stable30 please
/backport to stable29 please

🤖 Generated with Claude Code

[juliusknorr]

Thanks a lot for this, change makes sense 👍

[ArtificialOwl]

/backport to stable35

[ArtificialOwl]

rebase since #6209 should have fixed the faulty test

[ArtificialOwl]

/backport to stable34

[ArtificialOwl]

/backport to stable33