1

I'm currently developing a chrome extension that is mainly driven by a JS application. I'm able to send message between application and background page using long-lived connection until I reload the extension. Once it's reloaded, there is no way to connect to it (either from a content script or from the JS code using the extension ID). It keeps saying "Attemptin to use a disconnected port object". I tried switching to a one-time requests model, with no luck. After reloading the extension, the sendMessage callback is called without argument and the extension receives no message. I followed hints in this solution : chrome.runtime.sendMessage throws exception from content script after reloading Chrome Extension But it doesn't change anything.

What am I missing on this ?

Edit:

Here is how I set up the connection:

var port = chrome.runtime.connect()
// Then I use a DOM message to communicate with content-script :
window.addEventListener("message", function(message) {
    port.postMessage(message);
}
Community
  • 1
  • 1

2 Answers2

0

you arent missing anything. this is how it currently works. i dont like it either. this is very common because it happens when chrome auto updates an extension, even while in use.
i deal with this in my extension by detecting that specific error you mention. each content page then displays a small moddless dialog telling the user to either ignore or Reload the webpage. Plus for Trello chrome extension does this as of 2 days ago. while its not great, I took it as an oportunity to tell the users about new features using a link in the moddless dialog.
also, if you want to catch this on the background side, just parse your manifest (expose as a resource) and save in local storage the last version. you will detect it was updated. there is also onUpdated but ive never used it.
i guess if you really must communicate from content to the new extension you could write a message in a fixed storage.local property. background registers for storage changes and detects pending messages by reading that storage and removing it once processed. cant reply back unless you also use a local storage for the reply and do the same watching on the content side.

Zig Mandel
  • 19,571
  • 5
  • 26
  • 36
  • Sadly, reloading the page isn't enough in my case. I need to remove and reinstall the whole extension. And sadly, I use the extension to store my application state... :( – pchaussalet May 18 '15 at 19:25
  • thats something that needs further explaining. why would you require that? you will lose 99.9% of your users, and I don't see a technical reason for doing so. – Zig Mandel May 18 '15 at 19:26
  • Using the extension enables me to use unlimited storage. Losing my users is not a problem, it's a internal application that will be deployed on users chromebooks. That's why it is critical to me not to have to redeploy the extension each time it decide to stop working :) – pchaussalet May 18 '15 at 19:30
  • that still doesnt explain why you must remove and reinstall the extension. also see my updated answer – Zig Mandel May 18 '15 at 19:31
  • I saw your answer, thanks. But it doesn't occurs on auto updates, as I don't update my extension now, I'm still in development phase. Just activating "Allow in incognito" or reloading the application breaks the communication with the extension. There is no other way to re-enable communication than removing / reinstall the extension to make it work again. I tried to remove existing event handlers on content script injection, but it didn't change anything. – pchaussalet May 18 '15 at 19:51
  • then very likely something is wrong somewhere else in your code. I havent tried incognito scenarios, but I have been developing my extension for a couple years and never experienced that from my content pages, either in development or in published mode. My extension is normally used on several open tabs. – Zig Mandel May 18 '15 at 19:53
  • Thanks for the help @Zig-Mandel, you were right, the problem was somewhere else... :) – pchaussalet May 18 '15 at 22:40
0

Follow up on this problem: It appears there was a problem in my background page code that prevented calling chrome.runtime.onConnect. I fixed it and it works now.