Repository navigation
Federated document: closing the editor leaves a blank page since 10.3.0 #6094
Description
Describe the bug
Open a document received through a federated share (file owned by instance B, user on instance A). Closing the editor from the Collabora close button leaves a blank page: the viewer on A never closes. Escape or reload gets out of it.
Local documents are fine. Started with 10.3.0, still present in 10.3.1, 11.1.1, 12.0.0 and main. 10.2.1 is fine.
Same symptom as #5930, closed by #5934. That PR removed the openLocally TypeError but not the cause of the blank page: the message to the parent still goes to the wrong origin. On 10.3.0 (TypeError still there) fixing the origin alone is enough, because UI_Close is also forwarded to the parent before onClose() runs.
#5874 sets parent: window.location.origin as target origin in src/document.js and drops the '*' on close. On the remote page (/apps/richdocuments/remote, served by B inside an iframe of A) the parent window is A, not B: the browser silently drops every message sent to the parent, including close. B hides its editor, A keeps the viewer open with an empty iframe.
A already accepts messages from the federatedUrl origin (same PR, Office.vue); the remote side has no symmetric handling. remoteServer is already in the remote page query string.
To Reproduce
Steps to reproduce the behavior:
- Two instances A and B, federation and Nextcloud Office on both.
- B shares a folder with a user on A, user accepts.
- On A, open a document from that folder, click the close button in the editor.
Expected behavior
Viewer closes, file list is back.
Server details
Nextcloud 33.0.8, richdocuments 10.3.0, Collabora Online 25.04.12.3, Chrome 152 / Firefox 140.
"richdocuments": {
"federation_use_trusted_domains": "yes",
"public_wopi_url": [...],
"types": "filesystem,prevent_group_restriction",
"wopi_allowlist": [...],
"enabled": "yes",
"wopi_url": [...],
"disable_certificate_verification": "",
"doc_format": "",
"installed_version": "10.3.0"
Fix
--- a/src/document.js
+++ b/src/document.js
@@ initSession() {
const urlsrc = Config.get('urlsrc')
if (urlsrc) {
try {
+ let parentOrigin = window.location.origin
+ try {
+ parentOrigin = new URL(getSearchParam('remoteServer')).origin
+ } catch (e) {}
PostMessages.setAllowedOrigins([
new URL(urlsrc).origin,
window.location.origin,
+ parentOrigin,
])
PostMessages.setTargetOrigins({
loolframe: new URL(urlsrc).origin,
- parent: window.location.origin,
+ parent: parentOrigin,
})
} catch (e) {}
}Parent origin taken from remoteServer, fallback to self. No '*'. Verified on two production instances (Nextcloud 33.0.8, richdocuments 10.3.0): close works again, reshares included.
Activity
Rikdekker commentedon Oct 14, 2026
Thanks for the detailed report. I can reproduce it, and I opened #6190 with a fix.
I hit the same symptom with a share from another instance (richdocuments 10.3.0 on the owner's side, 33.0.9 on the recipient's side). It shows the same
postMessagetarget origin errors in the console and the same URL left behind (…&editing=false&openfile=true).One note on the proposed patch: on the current code,
getSearchParam()decodes withdecodeURI(), which leaves%3Aand%2FinremoteServer(https%3A%2F%2F…, ashttp_build_query()writes it).new URL()then throws, and the code falls back to the page's own origin, so messages still go to the wrong place. #6190 letsremote()pass the origin to the page instead. That value has already been through the trusted-server check and the token confirmation ingetRemoteFileDetails().Tested locally with two origins on one dev container, on stable33 (10.3.2) and on main. The fix is needed on the instance that owns the file, since that instance serves the remote page.
fix(federation): post messages to the initiator origin from the remot…