feat(web-app-external): handle Collabora UI_InsertGraphic and UI_InsertFile postMessages

[pedropintosilva]

Add frontend handling for Collabora's remote file insertion and document
comparison features. When oCIS sets EnableInsertRemoteFile and
EnableInsertRemoteImage in the WOPI CheckFileInfo response, Collabora
shows new menu items that send UI_InsertGraphic and UI_InsertFile
postMessages to the parent window.

• Add Host_PostmessageReady handshake: reply to App_LoadingStatus with
  Host_PostmessageReady so Collabora accepts Action postMessages.

• Handle UI_InsertGraphic: open a file picker modal filtered to image
  MIME types, resolve the selected file to a signed WebDAV download URL,
  and send Action_InsertGraphic back to the Collabora iframe.

• Handle UI_InsertFile: read callback and mimeTypeFilter from the
  Collabora message, open the file picker accordingly, and send back
  the appropriate Action (Action_InsertMultimedia or
  Action_CompareDocuments).

• Create InsertRemoteFileModal.vue: new modal component that embeds the
  oCIS file browser in embed mode, resolves the picked file to a
  download URL via clientService.webdav.getFileUrl(), and calls back
  with { filename, url }.

• Replace catchClickMicrosoftEdit with a unified handleAppMessage
  listener that handles all app iframe postMessages (UI_Edit,
  App_LoadingStatus, UI_InsertGraphic, UI_InsertFile).

Companion server-side PR: owncloud/ocis#12192

Signed-off-by: Pedro Pinto Silva pedro.silva@collabora.com

---

1. pnpm build passes
2. Manual end-to-end test passed — Compare Document flow worked fully, with tracked changes UI appearing:

and insert images from cloud storage:

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[CLAassistant]

All committers have signed the CLA.

[pedropintosilva]

2 workflows awaiting approval

I wonder if the workflow can be approved here

[LukasHirt]

@pedropintosilva thank you for this PR. We're currently in a process of rewriting our CI to GH actions. I would kindly ask you to have a little patience right now. As soon as the E2E tests pipelines are moved to GH action, this PR would need to be rebased and we could then run the workflows. I'll let you know as soon as it is ready.

[pedropintosilva]

@LukasHirt , JFYI I have signed the CLA, thanks.

[LukasHirt]

@pedropintosilva we have migrated our test suite to GH actions. Please, do a rebase so that this PR picks up on that. I will approve the workflows to run afterwards.

[pedropintosilva]

@LukasHirt , I think the workflows might need approval

[LukasHirt]

@pedropintosilva could you please do one more rebase. We now removed the sonarqube step from CI and use app instead which does not block external contributions. Rebasing should then make the CI finally run as expected. Sorry for the obstacles…

[DeepDiver1975]

Thanks @pedropintosilva — nice feature and the manual end-to-end evidence (Compare Documents + image insert) is great to see. Reviewing as maintainer. I'm requesting changes: there are a couple of real security gaps around postMessage origin handling, a duplication concern, and a direct collision with the open PR #13906 that need resolving before this can merge.

Security — postMessage origin handling

1. Incoming editor messages are not origin-checked. handleAppMessage parses and acts on any window message event regardless of event.origin. It will trigger loadAppUrl.perform('write'), open the insert modal, and (via the handshake) post Host_PostmessageReady in response to messages from any frame on the page. Any embedded/third-party frame can drive these flows. The companion PR #13906 explicitly guards this with if (appOrigin && event.origin \!== appOrigin) return. Please add the same origin check at the top of handleAppMessage.

2. postMessageToApp posts with target origin '*'. This broadcasts the message to whatever origin currently occupies the iframe. For Action_InsertGraphic/Action_InsertMultimedia the payload contains a signed WebDAV download URL — posting it with '*' risks leaking a credentialed URL to an unexpected origin. Derive the editor origin from appUrl and post to that specific origin (again, this is exactly what #13906 does with its appOrigin computed).

3. InsertRemoteFileModal.vue drops the verifyMessageOrigin check. This component is a near-verbatim copy of the existing web-pkg/src/components/Modals/FilePickerModal.vue, but it omits the verifyMessageOrigin(origin) guard that FilePickerModal runs at the top of both onFilePick and onCancel. Without it, a message handler acting on owncloud-embed:file-pick / owncloud-embed:cancel accepts those events from any origin. Please restore the useEmbedMode().verifyMessageOrigin(origin) check in both handlers.

Duplication / reuse

InsertRemoteFileModal.vue duplicates ~95% of FilePickerModal.vue (same iframe embed setup, embed-target=file, onLoad focus, the file-pick/cancel listeners). The only real delta is "resolve to a download URL and call onSelect" vs. "open the editor route". Consider factoring the shared embed-picker scaffolding into a composable or extending FilePickerModal with a pluggable "on pick" strategy, rather than maintaining two copies that can (and already did, re: the origin check) drift apart.

Collision with #13906 (same area — flagged in the task)

PR #13906 ("enable Collabora Save As / export to storage") is open and modifies the same App.vue: it also adds the Host_PostmessageReady handshake, useModals/dispatchModal, the iframe ref, the onBeforeUnmount listener cleanup, and replaces catchClickMicrosoftEdit with a unified switch handler — but with origin checking and a specific target origin. These two PRs will conflict and currently diverge on the security-critical origin handling. They should be reconciled: ideally land the hardened handshake/handler infrastructure once (the #13906 version with origin checks) and layer the insert handlers on top, so we don't ship two competing implementations of the same channel.

Behaviour notes / smaller points

• UI_Edit is now gated on determineOpenAsPreview(appName) inside the handler (previously the listener was only attached in that case). Net behaviour looks equivalent, good — just calling it out.
• The duplicate ref="appIframeRef" on both the GET and POST iframes is OK because they're mutually exclusive via v-if, but it reads oddly; a single shared ref or distinct refs would be clearer.
• IMAGE_MIME_TYPES works as a filter because the embed list filter matches against both resource.extension and resource.mimeType — confirmed, so MIME values are fine here.

Tests & CI

• The build check is currently failing (red) — please get CI green.
• There are no unit tests for the new postMessage handlers (handleAppMessage dispatch, the handshake, modal wiring) or for InsertRemoteFileModal. Given this is security-sensitive postMessage code, please add coverage — at minimum an origin-rejection test once the origin guards are in place. web-app-external/tests/unit/app.spec.ts is the natural home.

Changelog

changelog/unreleased/enhancement-collabora-insert-remote-file.md is present and follows the template/format. 👍

Summary: solid feature with working manual verification, but please (1) origin-check incoming messages, (2) post Action messages to the specific editor origin (not '*'), (3) restore verifyMessageOrigin in the modal, (4) reconcile with #13906, and (5) green CI + add handler tests. Happy to re-review once those are addressed.