如何避免“扩展上下文无效"?扩展名更新后发送消息时出现错误? [英] How to avoid "Extension context invalidated" errors when messaging AFTER an Extension update?

查看:175
本文介绍了如何避免“扩展上下文无效"?扩展名更新后发送消息时出现错误?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

发布更新后,我正在尝试为Chrome扩展程序的用户提供流畅的体验.

I am trying to create a smooth experience for users of my Chrome Extension after I release updates.

我在应用程序更新时重新注入了内容脚本,即使用户继续在扩展程序更新后未刷新的页面上继续使用我的扩展程序,我的功能也可以正常工作.刷新页面是理想的选择,但我不想强制将其强加给我的用户.

I reinject my content script on an update of the app, and my functionality works even if the user continues to use my Extension on a page that has NOT been refreshed after the Extension update. Refreshing the page is ideal, but I don't want to have to force that on my users.

但是,在扩展程序更新之后,但在代码尝试从内容脚本/页面发送消息到后台时,页面刷新之前,我在内容脚本控制台(将内容脚本插入的页面)中收到以下错误页面:

However, I get the following errors in my content script console (the page the content script is inserted into) AFTER the Extension updates but BEFORE the page is refreshed when my code attempts to message from the content script/page to my background page:

未捕获的错误:扩展上下文无效.

Uncaught Error: Extension context invalidated.

是否有一种重建"连接的方法?我尝试了长期使用的端口和常规消息传递-更新扩展具有相同的效果.

Is there a way to 'rebuild' the connection? I've tried a long-lived port and regular messaging - updating the Extension has the same effect.

任何想法/方向都表示赞赏.

Any ideas/direction appreciated.

这是我的简单消息传递代码(在内容脚本中),引发错误...但是可以与后台脚本进行通信:

Here is my simple messaging code (in the content script) that throws the error...but IS able to communicate with the background script:

chrome.runtime.sendMessage({ msg: "recordFeedback", obj: commentObj, source: source}, function(response){
  console.log('Sent to DB...response was: ', response, response.recordFeedbackResponse);
});

推荐答案

卸载扩展程序时,现有内容脚本将失去与扩展程序其余部分的连接,即端口关闭,它们将无法使用runtime.sendMessage(),但是内容脚本本身仍然可以继续工作,因为它们已被注入到页面中.

When an extension is unloaded, the existing content scripts lose their connection to the rest of the extension—i.e. ports close, and they would be unable to use runtime.sendMessage()—but the content scripts themselves still continue to work, as they're already injected into their pages.

重新加载扩展程序时是相同的:那些现有的内容脚本仍将存在,但无法发送消息;尝试这样做会导致类似您遇到的错误的错误.此外,由于扩展程序通常在加载时将其内容脚本注入现有选项卡(在Chrome上,Firefox会自动执行),因此最终会在给定的选项卡中运行多个内容脚本副本:原来的(现在已断开连接),而当前的已断开连接.

It's the same when an extension is reloaded: those existing content scripts will still be there, but unable to send messages; attempts to do so cause errors like the one you're encountering. Further, as it's common for extensions to inject their content scripts into existing tabs when they are loaded (on Chrome—Firefox does that automatically), you'll end up with more than one copy of the content script running in a given tab: the original, now-disconnected one, and the current, connected one.

如果出现以下情况,则可能会出现问题:(1)您的原始内容脚本仍在尝试与扩展的其余部分进行通信,或者(2)您的原始内容脚本执行了诸如修改DOM之类的操作,因为最终您可能会进行这些更改做不止一次.

Problems can arise if either: (1) your original content script is still trying to communicate with the rest of the extension or (2) your original content script does things like modify the DOM, as you could end up with those changes done more than once.

这可能就是为什么即使重新注入内容脚本后仍然出现错误:错误来自仍然存在但已断开连接的原始内容脚本.

这是我先前在研究此问题时发现的一些有用的背景信息.请注意,Firefox会自动卸载内容脚本(稍后会详细介绍).

This has paraphrased some helpful background information that I found when previously researching this problem. Note that Firefox automatically unloads content scripts (more on that later).

如果您不会自动重新注入内容脚本,则可以尝试获取现有脚本以在升级时重新连接,请按照上面 wOxxOm 的评论进行.

If you are not automatically re-injecting your content scripts, then you can try to get the existing script to reconnect on upgrade, as per wOxxOm's comment above.

这里有一些进一步的信息和建议,如果您注入新的内容脚本并希望禁用原始的,断开连接的(当您将其断开连接时)注入了新的.

Here's some further info and advice, particularly useful if you inject new content scripts and want to disable the original, disconnected, one when a new one is injected.

无论您是想尝试使用现有内容脚本重新连接,还是要停止对原始内容脚本进行进一步的更改并注入新的脚本,都需要检测是否已发生卸载.您可以使用端口的disconnect处理程序来捕获扩展程序的卸载时间.如果您的扩展仅使用简单的一次性消息传递,而不使用端口,那么该代码就像在您的内容脚本启动时运行以下代码一样简单(我首先在lydell ).

Regardless of whether you would like to try to reconnect using the existing content script, or stop the original content script from making further changes and inject a new one, you need to detect that an unload has occurred. You can use the port's disconnect handler to catch when your extension is unloaded. If your extension only uses simple one-time message passing, and not ports, then that code is as simple as running the following when your content script starts up (I first saw this technique in some code from lydell).

browser.runtime.connect().onDisconnect.addListener(function() {
    // clean up when content script gets disconnected
})

在Firefox上,未触发端口的disconnect ,因为内容脚本将在收到之前被删除.这样做的好处是不需要检测(手动内容脚本注入也不需要,因为内容脚本也会自动注入),但这的确意味着没有机会重置内容脚本对DOM所做的任何更改正在运行.

On Firefox, the port's disconnect is not fired, because the content scripts are removed before they would receive it. This has the advantage that this detection isn't necessary (nor is manual content script injection, as content scripts are injected automatically too), but it does mean that there's no opportunity to reset any changes made to the DOM by your content script when it was running.

这篇关于如何避免“扩展上下文无效"?扩展名更新后发送消息时出现错误?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆