9

I am in the process of converting a Chrome extension from manifest version 2 (MV2) to manifest version 3 (MV3). In the MV2 version, the background page script has a prominent role in the extension: At startup, the background script reads in a large amount of data from IndexedDB to RAM, and then (during operation) handles queries from content scripts injected into the pages that the user visits. To move to MV3, the functionality provided by the MV2 background script now needs to be translated to be performed by a MV3 service worker instead.

Because reading the data from IndexedDB to RAM is slow (relatively speaking), it is not feasible to do this dynamically upon a query from a content script; rather it must be performed by a service worker only once and then the data kept around in order to serve the incoming requests from the content scripts. Thus, the service worker should be persistent (and not be terminated by the browser); for this there exists at least one solution: https://stackoverflow.com/a/66618269/4432991

However, in some cases (I have not been able to pin-point exactly under what circumstances) when a content script sends a message to the service worker, Chrome starts up a second copy of the service worker, even while the first one is still alive, and the two service workers co-exist for some duration. Is there some way to avoid this, and ensure that if a service worker is still alive (in memory), no activity (by content scripts) will cause a second copy of the service worker to be created, and rather all requests by the content scripts will thus be handled by the previously existing service worker?

Thanks for any help!

wOxxOm
  • 65,848
  • 11
  • 132
  • 136
byb
  • 335
  • 2
  • 11
  • That's definitely a bug which you can report on https://crbug.com. – wOxxOm May 16 '21 at 17:13
  • Ok, I see, thanks. I'll need to try to find an easy way to reliably reproduce this, and write up a bug report detailing the problem. – byb May 16 '21 at 21:03
  • Meanwhile you can describe your use case in https://crbug.com/1152255. – wOxxOm May 17 '21 at 03:07
  • @byb, how did you proceed further? Did you have to revert to mv2? – Nikhil Sinha Jun 26 '21 at 07:52
  • 1
    @NikhilSinha, I did not in any case feel so happy about the workaround needed to keep the service worker around for more than 5 minutes, and then there was this issue too. It seems that, at present, the best option for me is to require the user to open (and keep open) a tab holding the extension page. That page can then provide UI for the extension, and also serve the function that the background page did in MV2. In other words, a script run by this extension page loads the IndexedDB data and then serves the requests sent by content scripts. If the tab is closed, the functionality is lost. – byb Jun 26 '21 at 19:48
  • @byb, interesting. In my case, the functionality of the extension is implicit, i.e., it does not have any extension pages of its own (and ideally, that's how I want to keep it). Regardless, I'll try playing with your idea. Thanks. – Nikhil Sinha Jun 28 '21 at 04:05
  • We're also having trouble with multiple service workers. This essentially breaks the app as requests are not responded too https://cdn.discordapp.com/attachments/1085229350787502151/1110664475301916752/image.png – kyranjamie May 24 '23 at 08:11

0 Answers0