Google chrome extension CSP问题，从chrome扩展加载了iframe

我正在开发一个chrome扩展，可以在Gmail中渲染和显示侧边栏iframe

不久前，我们遇到了一个内容安全策略问题，它破坏了我们的扩展，并遇到了一个众所周知的错误，该错误在您的控制台中显示为

拒绝框架“[OUR DOMAIN]”，因为它违反了以下内容安全策略指令：…

要修复它，我们必须重写CSP头，如中所述

然而，最近，我们得到了同样的错误，即使在实施了博客文章中建议的修复之后

如您所见，尽管我们添加了

chrome.webRequest.onHeadersReceived

侦听器来覆盖CSP头，但我们的域似乎没有工作。因此，我们的边栏无法加载

注意事项和尝试：

• 请注意，在刷新整个页面时，侧边栏有时会成功加载%50次，这使我相信我们添加上述事件侦听器的速度不够快。为了解决这个问题，我将事件侦听器从我们的后台类中拉出来，并将其放在后台js脚本的顶部。然而，这个问题似乎仍然存在

• 我们试图删除并重新添加扩展，但没有产生任何永久性的结果

• 在整个测试过程中，我还注意到，添加另一个在CSP头上实现类似覆盖的扩展将导致我们的扩展中断。删除并重新添加扩展将我们带回第一个注释中的50-50问题

[更新]

• 似乎有50%的时间能够复制它与chrome版本有关。升级到72后，我现在可以重现这个问题了。但是，对页面进行硬刷新有时会允许加载页面

• 有关设置的更多详细信息：我们所做的基本上是有一个包含html模板的background.html，还有一个包含iframe标记的模板。为了获得带有iframe的模板，我们执行了一个

  sendMessage

  ，获取响应，即字符串中的模板，通过jquery将其转换为DOM元素，将其附加到body中，并更改iframe的src属性。发生的情况是iframe最初加载良好，但是当您单击iframe中任何将重定向到另一个页面的链接时，上面显示的错误相同

---

如果需要，我可以提供代码片段和更多信息。

正如您在WebRequestAPI文档中所看到的，覆盖竞争中的赢家是完全不可预测的。我建议重新编写代码，这样您就不会从第三方域加载任何脚本（通常这是个坏主意），而是尽可能多地将其放入内容脚本中，或者放入添加到gmail页面的iframe元素中，该元素指向扩展名内的html文件（通过web可访问的资源公开），您可以在其中绘制主UI，边栏，随便什么。在该iframe中，您将能够拥有另一个指向自定义域的iframe。Hi@wOxxOm。我添加了“关于我们设置的更多细节”来解释我们的情况。我们基本上尝试注入一个iframe并操纵src。这项工作直到不久前才见效。我相信你的建议在某种程度上是正确的？你有什么不需要重做的建议吗？我这样问是因为返工对我们来说不一定是一种选择。试着禁用chrome://flags/#network-服务和顺便说一句，我建议用DOMParser API解析html。谢谢@wOxxOm。看起来这是他们之前版本的Chrome72的一个问题。他们刚刚发布了一个补丁。我们的扩展正在工作。嗨@Jack，我在chrome 81上遇到了类似的问题，在我的场景中，我正在使用chrome.webRequest.onHeadersReceived listener重写CSP和x-frame-options标题。这在ChromeV80及以下版本中运行良好。在v81中，您是否又面临同样的问题？