onlyOffice等外部插件放置在主应用内能正常使用，放置在子应用内不展示或者展示不全，怀疑外部插件部分内置方法被沙箱阻隔了

[ITboyfeifei]

已尝试使用InstanceofPlugin，EventTargetPlugin等插件，也试了jsIgnores和cssIgnores排除都不行，请问有遇到同类问题的吗，怎么解决得，非常感谢

[trofim24]

ONLYOFFICE (and any iframe SDK that talks to window.parent) renders blank in a Wujie sub-app - root cause + workaround

This is the same root cause behind #1083 (ONLYOFFICE), #703 (WPS setToken) and #549 (sub-app window.addEventListener('message') stops firing). Here is a full diagnosis and a drop-in integrator workaround, plus a suggestion for a Wujie-side fix.

Symptom

• Embedding ONLYOFFICE Document Server via the config API - new DocsAPI.DocEditor(container, config) - inside a Wujie sub-app shows a blank page / stuck loading skeleton. No errors in Console, all network requests succeed.
• The same sub-app works standalone, and a plain <iframe src=…> to the editor also works inside the same Wujie sub-app. Only the config/DocEditor path breaks.

Why (two independent problems, both from the sandbox↔host window split)

The editor <iframe> that api.js creates is rendered into the host document's Shadow DOM, so its window.parent is the host window. But api.js itself runs in Wujie's srcdoc JS sandbox. The api.js ⇄ editor postMessage handshake therefore crosses the sandbox/host boundary, and Wujie breaks it two ways:

1. message listeners are registered on the wrong window. "message" is in appWindowAddEventListenerEvents (common.ts#L189), so a sub-app's window.addEventListener("message", …) is bound to the sandbox window (iframe.ts#L160-L168). The editor iframe lives in the host document (effect.ts#L454, the case "IFRAME" branch appends it to the render root), so it posts onAppReady to the host window. api.js - listening on the sandbox window - never receives it, so it never sends init/openDocument. (This is exactly what #549 and #703 describe.)

2. parentOrigin mismatch. ONLYOFFICE api.js sets config.parentOrigin = window.location.origin. As a classic script it sees Wujie's proxied location, which returns the sub-app origin (proxy.ts#L215-L222, origin → urlElement.origin). But the sandbox is a same-origin srcdoc iframe whose real origin is the host origin (iframe.ts#L1063), and that is the origin the browser stamps on api.js's messages. The editor (Common.Gateway) silently drops any message whose event.origin ≠ parentOrigin → even once (1) is fixed, the editor rejects api.js's init.

Both must be corrected for the handshake to complete. (Confirmed by tracing: onAppReady arrives on the host window; nothing on the sandbox window.)

Integrator workaround (no Wujie or ONLYOFFICE changes)

Wrap the constructor: for that single synchronous call, route api.js's message listener to the host window and make the proxied location.origin return the real host origin; restore both after.

function createDocEditor(containerId: string, config: any) {
  const w = window as any;
  const DocsAPI = w.DocsAPI;
  const sandbox = w.__WUJIE;                 // present only inside Wujie
  if (!sandbox || !sandbox.proxyLocation) {  // standalone / plain <iframe>
    return new DocsAPI.DocEditor(containerId, config);
  }

  const hostWindow = w.parent && w.parent !== w ? w.parent : w; // use w.top when nesting
  let realOrigin = w.location.origin;
  try { if (hostWindow.location?.origin) realOrigin = hostWindow.location.origin; } catch {}

  // (1) parentOrigin -> real host origin
  const originalProxyLocation = sandbox.proxyLocation;
  sandbox.proxyLocation = new Proxy(originalProxyLocation, {
    get: (t, p) => (p === "origin" ? realOrigin : Reflect.get(t, p)),
  });
  // (2) api.js's "message" listener -> host window (where the editor iframe posts)
  const originalAddEventListener = w.addEventListener;
  w.addEventListener = function (type: string, listener: any, options?: any) {
    if (type === "message") return hostWindow.addEventListener(type, listener, options);
    return originalAddEventListener.call(w, type, listener, options);
  };

  try {
    return new DocsAPI.DocEditor(containerId, config);
  } finally {
    sandbox.proxyLocation = originalProxyLocation;
    w.addEventListener = originalAddEventListener;
  }
}

Part (2) is essentially Wujie's own addEventListener(type, fn, { targetWindow }) option (iframe.ts#L162) applied to a third-party library whose addEventListener call you cannot modify.

Suggested Wujie-side improvement

For a sub-app that embeds a third-party iframe SDK using postMessage(window.parent, …) (ONLYOFFICE, WPS, OAuth/payment widgets, …), the sandbox-vs-host window split makes it impossible without the workaround above. Possible directions:

• document this pitfall and the targetWindow escape hatch prominently; and/or
• optionally relay message events between the host window and the sandbox window for sub-app-created iframes; and
• document that proxied location.origin (sub-app origin) differs from the sandbox's real origin (host), which silently breaks origin-checked postMessage handshakes.

Related: #1083, #703, #549.

---

中文

ONLYOFFICE（以及任何通过 window.parent 通信的 iframe SDK）在 Wujie 子应用中白屏 -- 根因与解决方案。这与 #1083（ONLYOFFICE）、#703（WPS setToken）、#549（子应用 window.addEventListener('message') 失效）是同一个根因。

现象

• 通过 config 方式 new DocsAPI.DocEditor(container, config) 在 Wujie 子应用中嵌入 ONLYOFFICE Document Server，文档区域白屏 / 一直停在加载骨架；Console 无报错，网络请求全部成功。
• 独立运行该子应用正常；在同一个 Wujie 子应用里用普通 <iframe src=…> 也正常。只有 config / DocEditor 这条路径失效。

原因（两个相互独立的问题，都源于 沙箱window 与 主应用window 的分裂）

api.js 创建的编辑器 <iframe> 被渲染进主应用文档的 Shadow DOM，因此它的 window.parent 是主应用的 window；而 api.js 本身运行在 Wujie 的 srcdoc JS 沙箱里。于是 api.js ⇄ 编辑器 的 postMessage 握手跨越了 沙箱/主应用 边界，Wujie 在两处打断了它：

1. message 监听被注册到了错误的 window。 "message" 在 appWindowAddEventListenerEvents 中（common.ts#L189），所以子应用的 window.addEventListener("message", …) 被绑定到沙箱 window（iframe.ts#L160-L168）。而编辑器 iframe 位于主应用文档（effect.ts#L454 的 case "IFRAME" 分支把它插入渲染根），因此它把 onAppReady 发到了主应用 window。监听在沙箱 window 上的 api.js 收不到，也就永远不会发送 init/openDocument。（这正是 #549、#703 描述的情况。）

2. parentOrigin 不匹配。 ONLYOFFICE api.js 会 config.parentOrigin = window.location.origin。作为普通脚本，它读到的是 Wujie 代理后的 location，返回的是子应用 origin（proxy.ts#L215-L222，origin → urlElement.origin）。但沙箱是与主应用同源的 srcdoc iframe，其真实 origin 是主应用 origin（iframe.ts#L1063），这也是浏览器给 api.js 消息打上的 origin。编辑器（Common.Gateway）会静默丢弃 event.origin ≠ parentOrigin 的消息 -- 所以即便修好了(1)，编辑器也会拒收 api.js 的 init。

两处都修好，握手才能完成。（抓包已确认：onAppReady 到达主应用 window，沙箱 window 上没有任何消息。）

接入方的解决方案（无需改动 Wujie 或 ONLYOFFICE）

包一层构造调用：在这一次同步调用期间，把 api.js 的 message 监听改到主应用 window，并让被代理的 location.origin 返回真实的主应用 origin，调用后立即还原。（代码同上英文部分。）

其中第 (2) 步本质上就是 Wujie 自带的 addEventListener(type, fn, { targetWindow }) 选项（iframe.ts#L162），只不过应用到了一个你无法修改其 addEventListener 调用的第三方库上。

对 Wujie 的改进建议

当子应用需要嵌入通过 postMessage(window.parent, …) 通信的第三方 iframe SDK（ONLYOFFICE、WPS、OAuth/支付组件 等），沙箱/主应用 window 的分裂会导致无法直接使用。可能的方向：

• 在文档中显著说明该坑，以及 targetWindow 这个逃生通道；
• 可选地为「子应用创建的 iframe」在主应用 window 与沙箱 window 之间中转 message 事件；
• 说明「代理后的 location.origin（子应用 origin）与沙箱真实 origin（主应用）不一致」会静默破坏带 origin 校验的 postMessage 握手。

相关：#1083、#703、#549。