Question

我的Chrome扩展程序存在问题，这取决于 chrome.tabs API。

我的扩展程序大多正常运行。有时候我做了 chrome.runtime.reload()并且大部分没有问题，但是偶尔（我无法预测何时或可靠在重启后返回后台脚本时复制它 chrome.tabs引用为undefined。因为我依赖那个API 扩展无法启动。可以检测到这种情况，但是当我尝试做chrome.runtime.reload()，chrome.runtime.reload也是 undefined。所以我没有再次重启的方法。

我意识到我可能应该开发软重启功能我的扩展程序返回到空白状态，但这是非常有效的密集，所以我想询问社区是否有其他任何人遇到这个问题，在那种情况下，你是如何解决的它？

以下是manifest.json文件的权限：

 "permissions": [
   "tabs",
   "contextMenus",
   "webNavigation",
   "webRequest",
   "webRequestBlocking",
   /* some whitelisted web URLs... */

Answer 1

非常感谢@Xan 指着我this other 这个问题似乎涵盖了完全相同的现象。

我已经确定有足够的迹象表明这是一个错误在chrome处理背景页面。

我还有一些额外的意见：

@Xan指出的问题引用了一个可能的错误 Chrome的背景页。
当我通过调用我的chrome.runtime.reload()来复制错误时后台页面的开发者工具控制台我发现了 chrome.runtime.reload()像往常一样可用于我的扩展程序弹出UI。
背景页面（尚未）已弃用，但是在第一行中 documentation 建议迁移到事件页面，但它们不可能在Chromium团队的优先级列表中占据优势。换句话说，我考虑一下这个错误的风险 - 如果是一个 - 有很高的存在风险因此，对'wontfix'进行分类，尝试看起来没有效果等待修复。

因此，我设计了一种我认为会有的解决方法在我有资源开发之前一直很满意我的扩展程序中的软重启功能 OR 迁移到事件页面：

鉴于：

我的大多数扩展功能都是通过Chrome触发的 browserAction。在浏览器操作开始渲染之前，我可以将消息发布到我知道将回拨的后台页面立即
当扩展程序正常启动时，修复程序将只是一个 no-op对最终用户不可见。
由于修复正常操作是无操作，修复不会伤害到如果Chromium团队在将来的版本中修复了该错误，那么应该进行扩展。
“死”背景页面无法注册任何消息监听器。如果背景页面没有响应安全检查消息，弹出窗口可以通过重新启动来修复损坏的状态扩展

这需要付出代价：如果弹出窗口等待'安全' net'消息并重新启动，弹出UI将被残酷关闭没有警告从最终用户的脚下。不好 - 但之后一些考虑我已经决定我认为这种行为是远的优于扩展只是默默地停止工作现在可以做。

如果您有进一步的想法，请评论！

Chrome扩展程序：chrome.runtime.reload（）

1 个答案: