Skip to content

Federated document: closing the editor leaves a blank page since 10.3.0 #6094

Closed

Description

@n-iv

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:

  1. Two instances A and B, federation and Nextcloud Office on both.
  2. B shares a folder with a user on A, user accepts.
  3. 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

  1. added theissue type on Sep 30, 2026
  2. Rikdekker commented on Oct 14, 2026

    @Rikdekker
    Contributor

    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 postMessage target 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 with decodeURI(), which leaves %3A and %2F in remoteServer (https%3A%2F%2F…, as http_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 lets remote() pass the origin to the page instead. That value has already been through the trusted-server check and the token confirmation in getRemoteFileDetails().

    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.

  3. added a commit that references this issue on Oct 20, 2026
    d22fa75
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions