If you can attach a basic extension that simply reproduces the issue (preferably, only this issue and no other functionality), that would help to triage this.

Apparently, the reasoning was to ensure security: all parts of an extension share same execution context, tracked internally in the browser. When the background page is reloaded, it's effectively destroyed and recreated thus no longer part of that context.

In short, the idea of this bugreport is to consider a possibility of reattaching "orphaned" contents scripts to the new context of the reloaded extension. Or maybe find another solution. The obvious challenge is whether it's possible to reliably avoid spoofing by a malicious 3rdparty extension.

#3 - this does not happen when the background page is reloaded, it only happens when the extension is disabled and enabled (while this is also causing the background page to reload, it is not a required part, I imagine it would be the same with a regular extension page), even for code that is run using executeScript calls that occurred after the extension is re-enabled. This sounds like a bug (it is a new context, so why would not work?). A low priority bug, but a bug.

Just to be sure I'm understanding things, you're saying that if the extension had previously injected script via executeScript on a given page, then was disabled and re-enabled, that newly injected script (via executeScript) cannot call sendMessage? (It's somewhat expected that the old script context from before the disable/re-enable will be unable to connect, but the new script should be able to)

Yup, This is what I believe I'm seeing.

After enabling the extension I query for all the tabs and then execute the executeScripts again. The ones that never had the content script executed on them work fine as expected. But the previous ones I can never recover besides forcing a reload. 

It seems/sounds like what Aaron is referring to is some what expected behavior per  http://crbug.com/168263 

I've been troubled over the same message, it used to be that an exception with the message  "Error connecting to extension xxxxxx" would be thrown when an extension was disconnected. That seems to have been replaced by "Invocation of form runtime.connect(null, ) doesn't match definition ...."  This change in behavior appears to been introduced a year ago for  http://crbug.com/537666  when the unload_event was removed.

Our chrome extension handles these issues gracefully by overriding and detecting exceptions in the runtime.sendMessage callback, although a better solution would be ideal for Chrome Extension context scripts to notify them a connection isn't available. The current error doesn't account for the extension being disconnected from the context script.

Looking at some old code, line 142, reflects that if no PortId was available an exception with the appropriate message would be thrown.
https://searchcode.com/file/32977419/src/chrome/renderer/resources/extensions/extension_custom_bindings.js

This is not the case in the current code, perhaps adding that back may clear up some confusion?  See line 161, exception is missing
https://cs.chromium.org/chromium/src/extensions/renderer/resources/runtime_custom_bindings.js?type=cs&sq=package:chromium

Hi br...@bombbomb.com - 

Would you mind showing me the snip of code you use to handle this gracefully? I know I can catch this exception there but then how do you get the page to reconnect?  Thanks. 

Aaron,
I haven't found a easy way to reconnect without having to refresh the page, although we do prompt the user that the feature is unavailable and they need to refresh. The other option is to refresh the page automatically although that can tend to upset people to interrupt work that's in progress.

To refresh we just update the window.location, nothing fancy.  I'm still digging to see if it's possible to reconnect without prompting the user.

This issue also happens when extension users disconnect and connect internet.
More realistically, when someone doesn't shut down the laptop, pull down the screen and open the laptop again at a later point. This activity, disconnects and connects internet. 

I am facing the same error even in that secnario. Although not always but sometimes, which is making it difficult to replicate the issue.

The issue gets easily resolved when i refresh the page where content script is loaded.

Is there no solution to this issue yet?

I observe this issue as well. For instance, while developing an extension I hit Ctrl+R, so all other extensions are also reloaded, and a bit of chaos described above ensues.

This is a hard one to handle. One idea is to remove injected content scripts upon disabling the extension, but then you would have to retrospectively unregister all event handlers that were registered by the content script also.

For Aaron and others, here is something like the method we're using to help deal with this so our feature gracefully fail. It would be nice if Chrome could provide a native error handling at least, doing the override is a bit messy but we use also use it to proxy callbacks.

function SendMessageOverride(onDisconnected,exceptionLogger)
{

    var chromeSendMessage = chrome.runtime.sendMessage;
    chrome.runtime.sendMessage = function() {
        try
        {
            chromeSendMessage.apply(this,arguments);
        }
        catch (e)
        {
            if (e.message.indexOf('connecting to extension') !== -1 || e.message.indexOf('Invocation of form runtime.connect') !== -1)
            {
                backgroundDisconnected = true; // this is a global
                onDisconnected({error: 'Connection to Background Error', message: e.message});
            }
            else
            {
                onDisconnected({error: 'sendMessage Exception', message: e.message});
            }
            exceptionLogger.log('runtime.sendMessage Exception: '+e.message,{ stack: e.stack });
        }
    };

}

A simpler connectivity check should do the trick I think:

function isBackgroundConnectable() {
  var port = chrome.runtime.connect();
  if (port) {
    port.disconnect();
    return true;
  }
  return false;
}

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This happens to me too...
any suggestions?

Assaf, the usual workaround is to reinsert the content script via chrome.tabs.executeScript.

This looks like something worth addressing if we have the resources.