0

I am working on a Chrome extension which is designed to inspect the content of any web page the user navigates to, and then alert the user to certain "features" of that content. (Perhaps it is easiest to think of a large number of strings that are searched for in the text data of the web page, though this is a pretty big simplification.) By design, there is a very large set (tens of millions) of features that the extension detects and thus can react to. Each such feature can be represented as a JS number (8 bytes), so the total amount of data might be on the order of 100 MB, or more.

That data can be stored in IndexedDB, but to be able to quickly analyze the page data (as sent by the content script), the background page script (in MV2) or service worker (in MV3) really needs to have the features (which are checked for) stored in RAM, to be able to quickly check a much smaller but still large number of features from the webpage, to see if any of those are present in its own dataset.

This setup actually worked fine in a prototype manifest version 2 (MV2) extension I created. The background script would start by initially grabbing the data from IndexedDB and placing it in a structure in RAM. This takes a bit of time on my laptop (some number of seconds, I don't have precise numbers) but only needs to be done once when the browser is started. After that, the background script is able to quickly react to requests from the content script to check the webpage contents.

Now, trying to make the transition to manifest version 3 (MV3), the problem is that service workers are not persistent, nor even particularly long-lived. So a direct translation would have the service worker do the expensive and slow load from IndexedDB to RAM each time it is restarted. This is clearly not a working setup.

The obvious question then is: Is there some way to avoid Chrome stopping the service worker (and thus have the extension service worker persist for a long period)? If not, is there some way that the data in RAM could stay around, and the service worker grab access to it when starting up? (I am far from an expert on Chrome extensions and service workers, so I apologize if my questions are naive.) I read some discussions that seemed to suggest that perhaps neither of the above is currently possible, but if so, it would basically make the entire concept a non-starter under MV3. Are there any workarounds? (If yes, are those workarounds acceptable in the Chrome Web Store review process?)

I would be very grateful for any pointers!

byb
  • 215
  • 2
  • 9
  • 1
    See the workaround I described [here](https://stackoverflow.com/a/66618269) but you should describe this on https://crbug.com because Chromium's extension team keeps claiming they didn't see any need in a persistent background script (this isn't very surprising as they don't have any experience at all in writing or even maintaining a complex extension, those Chromium developers who do aren't a part of the extensions team). – wOxxOm May 05 '21 at 18:11
  • Thanks @wOxxOm for the quick response and the provided workaround. Though it seems something like that workaround might cause troubles in the Chrome Web Store review process? Or the browser might forcibly stop the extension after a while anyway? Are there any guarantees that this would be acceptable or work for any definite period of time? (And yes, I'll go complain on crbug.com...) – byb May 05 '21 at 18:21
  • CWS would have to hire actual programmers to detect this workaround so I doubt they'll ever do that as programmers are expensive. Chrome doesn't stop extensions but if it will in the future then it would mean the end of any complex extensions so you should probably forget about using Chrome. – wOxxOm May 05 '21 at 18:46
  • @wOxxOm I was perhaps thinking there might be automated ways for the CWS to run checks (for example, some check for how long a service worker runs continually), and it would seem a major risk to build something that goes against some general policies they have. Hmm... I suppose another workaround might be to simply require users to keep open an actual tab with some UI/status for the extension, perhaps then that tab could provide the persistence require (though I am not sure this is even feasible, and even if so, it is not a good solution for the users)... – byb May 06 '21 at 04:49
  • CWS can't know what the browser is doing. There's no such policy so I was just being paranoid because the extensions team has been suspiciously dumb about this particular problem but maybe it's just their lack of experience multiplied by arrogance, who knows. – wOxxOm May 06 '21 at 06:34

0 Answers0