New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于 iframe 沙箱 document 的疑问 1. body, head 2. rawRootElement,rawRootNode 原型代理) #1152
Comments
1、2是同一件事,html, body, head, title全局唯一,不可被代理,但需要处理其内部元素的操作 |
主应用 document.querySelector被代理,可以尝试使用removeDomScope方法解决,参考 https://micro-zoe.github.io/micro-app/docs.html#/zh-cn/dom-scope?id=%e8%a7%a3%e9%99%a4%e5%85%83%e7%b4%a0%e7%bb%91%e5%ae%9a |
一、二方业务这种处理倒还好,担心会有处理不完全的三方包,而且这个主系统 document 何时受影响的并不稳定(只要在子系统 window、document 有属性被访问,且还没执行 defer removeDomScope 的时候都有可能触发) |
这里会有问题,在使用 Antd#Modal 组件的时候指定 document.body 为挂载点的情况下,会存在内部 同样的如果子系统内有
这里的全局唯一是有相关规范吗?实际效果上是会影响子系统执行预期的 |
我现在是在打包时检查这个代码:document.body instanceof HTMLElement |
当前在使用 iframe 沙箱,偶现的存在主系统 document.querySelector 访问一个必然存在的节点时返回为空,导致程序崩溃
debug 发现主系统的 document.querySelector 也被代理了,在运行时依赖 currentAppName 表现行为不一致(currentAppName 存在时代理到子系统的 micro-app-body 内了)
继续排查发现是 IframeSandbox.start 阶段通过 patchElementAndDocument 进行了原型的更改,影响了全局 document 的行为
问题:1. iframe 沙箱内已经进行了 microDocument 的代理,为什么这里还需要进行
patchElementAndDocument
(patchElementAndDocument 内依赖 throttleDeferForSetAppName 设置 & 清理 currentAppName,清理行为简单 defer 不可控)移除 sandbox.start 内的 patchElementAndDocument 影响主系统 document 的行为消失
继续看 iframe 沙箱内 document 的 html, body, head, title 属性被代理到 rawDocument 同名属性上,同时在访问时调用了
throttleDeferForSetAppName
这里为什么不能直接返回micro-app#name=${appName}
micro-app/micro-app-body/micro-app-head 这几个节点?问题:2. iframe 内 document 属性代理到 rawDocument 上的考虑是什么,是否可以调整为 micro-app 内对应节点
The text was updated successfully, but these errors were encountered: