keuby

[micro-zoe-micro-app-v1.0.0-rc.4.tgz](https://github.com/micro-zoe/micro-app/files/14321418/micro-zoe-micro-app-v1.0.0-rc.4.tgz) 用这个包替换 node_modules 下面的对应文件尝试一下，记得需要删除 node_modules/.vite 文件夹清除缓存。

理论上，https://github.com/micro-zoe/micro-app/pull/985 这个 PR 可以解决这个问题

和 #1089 这个 issue 有点类似。 [micro-zoe-micro-app-v1.0.0-rc.4.tgz](https://github.com/micro-zoe/micro-app/files/14321418/micro-zoe-micro-app-v1.0.0-rc.4.tgz) 用这个包替换 node_modules 下面的对应文件尝试一下，需要删除 node_modules/.vite 文件夹清除缓存。

这个特性对于需要适配 Firefox 的情况下非常有用 在 Chrome 中，在 iframe 沙箱中创建的 dom 元素，插入到沙箱外的 html 中后，其依然是沙箱中 HTMLElement 的实例 但是在 Firefox 中，沙箱中创建的 dom 元素插入沙箱外后，他就变成了基座的 HTMLElement 的的实例了，此时沙箱中对于 dom 元素使用 instanceof 的判定全都会出错。

@nihaotdb 可以，这个 PR 的构建版本已经在我们项目的生产环境运行了一个多月了，我们的子应用也有使用 wangEditor 的，没有发现问题。

@nihaotdb 你可以把 [micro-zoe-micro-app-1.0.0-rc.3.tgz](https://github.com/micro-zoe/micro-app/files/13915111/micro-zoe-micro-app-1.0.0-rc.3.tgz) 引入到项目中试试是否可以解决，这个文件包含了这个 PR 的代码

基本上可以确定是浏览器的 bug, 我测试下来，Chrome 86,90,92 都有这个问题，Chrome102 以及之后的版本没有这个问题，应该是在 Chrome 92-102 之间哪个版本修复了这个 bug。 通过 Chrome 网络日志分析，在这个 pending 的请求发送之后，请求数据已经拿到了，一直在两个错    Chrome 应该是一直在重试，大概每 2 s 重试一次。从日志上看，Chrome 一直在尝试连接一个 ipv6 的地址，然后一直报错 (ERR_ADDRESS_UNREACHABLE)，就一直卡在这里了。

可以通过在 html 中注入代码来解决 在 html 中注入如下代码块： ```html if (window.__MICRO_APP_NAME__) { const umdKey = `micro-app-${window.__MICRO_APP_NAME__}`; function tryRun(name, fn) { if (window[umdKey][name] === fn) { setTimeout(fn, 100); } else { window[umdKey][name](); }...